#raku-dev on 28 May 2020 - Raku Programming Language Log

ShimmerFairy

My probably bad suggestion would be to allow method foo(@args):D { } so you don't have to worry about method foo:D(@args) { } (or even method:D foo(@args) { } as another option)

00:59

timotimo

and methods without argument signatures would be "method foo:D { ... }" then?

01:00

ShimmerFairy

Yeah, I was thinking more "another location to put adverbs", so attaching it to the name would still be OK.

01:01

timotimo

01:02

to me, if it's after the signature, and outside, it kind of reads a little like "related to return type", kinda like "is rw"

ShimmerFairy

Actually, attaching it to the keyword would make sense for things that could be see as affecting what kind of sub/method/etc. you're making, e.g. "This isn't just any method, but a 6.c only method"

01:03 lucasb left

ShimmerFairy

method:LANG<6.c> foo() { ... }; method:LANG<6.d> foo() { ... };

01:03

timotimo

metho:D and meth:U:d

01:04

ShimmerFairy

Also, I'm fine with the idea of reserving uppercase adverb names, but there had better be a clear line between adverbs and ordinary colonpairs. sub bar:CUSTOM-NOT-OK<...>(:$CUSTOM-OK) { }

01:07

Ooh! Attaching adverbs to the keyword means anonymous subs can be modified too! pass-a-func($arg, sub:LANG<6.c> { ... })

01:10

02:48 linkable6 left, evalable6 left 02:50 linkable6 joined 02:51 evalable6 joined 05:14 Xliff left 06:50 domidumont joined

moritz

eeks!

07:02

nine

But, but, why not just `multi method foo ($b) is LANG<6.e+> { ... }`? With a simple `sub trait_mod:<is>(Method $m, Version(Str) :$LANG!) { }` that already parses today and just needs the trait to set some field on the multi candidate that the dispatcher checks

07:09

We don't need such a mechanism for subs as we can just override lexically in the new language version's setting.

07:31 MasterDuke joined

ShimmerFairy

I was just working in the confines of "how can we do this adverbly?"

07:33

And besides, putting aside LANG specifically, the question of how to deal with sub foo:adv($function, $args) { } may well come up someday.

07:36

07:54 JJMerelo joined

JJMerelo

m: rule r { (\w+ '.')* \w+ }; say "a.b" ~~ r

07:55

camelia

5===SORRY!5===
Undeclared routine:
r used at line 1

Other potential difficulties:
Useless declaration of a has-scoped method in mainline (did you mean 'my rule r'?)
at <tmp>:1
------> 3rule 7⏏5r { (\w+ '.')* \w+…

JJMerelo

m: my rule r { (\w+ '.')* \w+ }; say "a.b" ~~ r

07:56

camelia

Too few positionals passed; expected 1 argument but got 0
in regex r at <tmp> line 1
in block <unit> at <tmp> line 1

JJMerelo

m: my rule r { (\w+ '.')* \w+ }; say "a.b" ~~ &r

camelia

｢a.b｣
0 => ｢a.｣

JJMerelo

m: my rule r { (\w+ '.')* \w+ }; say "a.b" ~~ &r

camelia

｢a.b｣
0 => ｢a.｣

JJMerelo

m: my token r { (\w+ '.')* \w+ }; say "a.b" ~~ &r

camelia

｢a.b｣
0 => ｢a.｣

JJMerelo

commit: releases my token r { (\w+ '.')* \w+ }; say "a.b" ~~ &r

07:58

committable6

JJMerelo, ¦releases (43 commits): «｢a.b｣␤ 0 => ｢a.｣␤»

JJMerelo

commit: releases my rule r { (\w+ '.')* \w+ }; say "a.b" ~~ &r

committable6

JJMerelo, ¦releases (43 commits): «｢a.b｣␤ 0 => ｢a.｣␤»

07:59

JJMerelo

So rules behave exactly the same as tokens. There's no :sigspace difference

m: my token r { [\w+ '.']* \w+ '.' \w+ }; say "a.b.c" ~~ &r

08:00

camelia

Nil

JJMerelo

m: my rule r { [\w+ '.']* \w+ '.' \w+ }; say "a.b.c" ~~ &r

camelia

｢a.b.c｣

JJMerelo

commit: releases my rule r { [\w+ '.']* \w+ '.' \w+ }; say "a.b.c" ~~ &r

committable6

JJMerelo, ¦releases (43 commits): «｢a.b.c｣␤»

08:01

JJMerelo

I am checking this stackoverflow.com/questions/620517...and-a-rule and it seems as if all it's in the documentation is wrong

tokens ratchet, rules don't. They both have non-significant whitespace. There does not seem to be a difference between a regex and a rule, then.

08:02

ShimmerFairy

default <.ws> does not require whitespace except between two word characters

08:04

JJMerelo

ShimmerFairy far as I can tell, that's not what the documentation says. But what about ratcheting?

08:12

ShimmerFairy

rule should absolutely be ratcheting, and if it isn't that's a bug.

But the default <ws> has always been / <!ww> \s* /

JJMerelo

commit: releases my rule r { [\w+ '.']* \w+ '.' \w+ }; say "a.b.c" ~~ &r

08:14

committable6

JJMerelo, ¦releases (43 commits): «｢a.b.c｣␤»

JJMerelo

commit: releases my token r { [\w+ '.']* \w+ '.' \w+ }; say "a.b.c" ~~ &r

committable6

JJMerelo, ¦releases (43 commits): «Nil␤»

08:15

JJMerelo

ShimmerFairy if it does, then it's a long standing bug...

The commit that changed that part of the documentation is 5 years old github.com/Raku/doc/commit/3c20a9f...7d5e2583bb

Sorry, afk now...

ShimmerFairy

m: my token r { a+ a }; say "aaaaa" ~~ &r

08:17

camelia

Nil

ShimmerFairy

m: my rule r {a+a}; say "aaaaa" ~~ &r

camelia

Nil

ShimmerFairy

m: my rule r { a+ a }; say "aaaaa" ~~ &r

camelia

Nil

ShimmerFairy

m: my regex r { a+ a }; say "aaaaa" ~~ &r

camelia

｢aaaaa｣

08:20 JJMerelo left

jnthn

I'm guessing this is a mis-compile in some situation, but I didn't yet figure out exactly what are the ingredients.

09:20

It's losing a ratchet somewhere

(None in any of those cut-down cases, though..)

*Not

09:44 Altai-man_ joined 09:54 JJMerelo joined

JJMerelo

jnthn is that bug posted somewhere?

09:55

jnthn and does that happen always, or only in some situations?

jnthn

JJMerelo: It's the first time I can recall seeing it. And I think the above evaluations show "only sometimes"

10:00

Maybe only if there's a quantified group

JJMerelo

jnthn++

jnthn

JJMerelo: If you've a moment, please do make an issue. If nobody beats me to it, I'll have a big in the regex compiler, but my brain is full of dispatcher stuff at the moment.

10:06

JJMerelo

jnthn by all means.

10:07

jnthn

s/big/dig :)

.oO( I'm big in the regex compiler )

Altai-man_

.oO ( maybe not da biggezt, but da strongezt for sure )

10:10

nine

jnthn: isn't grammar matching just a special case of dispatch? :P

ShimmerFairy

.oO(Non-deterministic Finite Dispatcher)

10:11

jnthn

Actually, the design dispatch programs at polymoorphic sites basically does look just like a finite automata, just over arguments instead of chars :P

10:14

*design of

10:28 sena_kun joined 10:30 Altai-man_ left

Geth

problem-solving: JJ++ created pull request #202:
Solution for issue #72: spin off module publishing tutorial in the documentation.

10:36

10:42 squashable6 left

ShimmerFairy

nqp: say(nqp::sprintf("%08.e", [1])); say(nqp::sprintf("%-8.e", [1])); say(nqp::sprintf("%-08.e", [1]));

10:44

camelia

0001e+00
1e+00
001e+000

10:44 squashable6 joined

ShimmerFairy

The handling of the '-' and '0' flags in %e seems broken to me, or is adding one of the zeros in the exponent intentional?

10:45

10:51 JJMerelo left 11:07 MasterDuke left

lizmat

ShimmerFairy: it is not

11:08

ShimmerFairy

That's what I figured. I would expect - to override 0 and put spaces on the right, like in other directives.

11:12 finsternis joined 12:27 Altai-man_ joined 12:30 sena_kun left 13:04 MasterDuke joined

Kaiepi

i was taking a bit of a break from things for a couple weeks, i'll get all those open prs rebased later today

13:06

13:39 MasterDuke left 13:57 MasterDuke joined 14:28 sena_kun joined 14:29 Altai-man_ left 14:38 MasterDuke left

[Tux]

Rakudo version 2020.05.1-206-g986f8ab6b - MoarVM version 2020.05-15-g644533ad1

csv-ip5xs	0.823	-	0.839
csv-ip5xs-20	7.899	-	8.396
csv-parser	26.650	-	27.086
csv-test-xs-20	0.394	-	0.419
test	7.748	-	7.990
test-t	1.870	-	1.939
test-t --race	0.932	-	0.933
test-t-20	31.992	-	33.099
test-t-20 --race	8.695	-	8.867

14:48

nine

So, my <unit-outer> seems to be missing it's outer, which is why symbols from the setting are just not available at runtime. It's missing already in the mbc file. That's odd however as I clearly give it an outer using nqp::forceouterctx (which I just documented as well) as evidenced by the debug output: forceouterctx(0x6e39d30, 0x5d22830), replacing sf 0x4b03538 <unit-outer>(nested) 91 outer (nil) with