00:00 atweiden left
dha I just noticed that C<my $foo = "ha";say "beep" if $foo == 0;> works differently in p6 than it does in p5. It looks like in p5 it treats a string with no digits as 0 in a numeric context, but p6 errors out. 00:08
I assume that's intentional?
TimToady yes 00:09
we also treat string '0' as true now, and only '' is false 00:10
on the theory that each normal type should have one distinguished false value, not two...
00:11 [Tux] joined
TimToady (and because p6 knows the difference between a string and a number to a greater extent than p5 does) 00:11
dha aha.
timotimo we should have an opt-out to get a 0 that's True ... like 00 instead of just 0. you know, to go with "0" ... because "" vs "0" created the rule that putting a 0 in front makes it true 00:12
TimToady a lot of the differences keep coming back to the type system, because a lot of the original RFCs were underlyingly complaints about the lack of one
timotimo i think my brain is desperate for some sleep 00:13
TimToady that's so 00
b2gills m: my $a = 0 but True; say $a if $a 00:14
camelia rakudo-moar 4a7219: OUTPUT«0␤»
TimToady well, if you want a 2-character 0 that is true, try ~0 then :P
timotimo that looks a tiny bit like a winking emoticon 00:15
TimToady m: my $a = ~0; say $a if $a
camelia rakudo-moar 4a7219: OUTPUT«0␤»
dha m: my $a = -0;say $a if $a
camelia ( no output )
dha uh...
why did we just get different results? 00:16
TimToady guesses dha's font makes ~ look like -
dha Upon closer looking, yeah. I think I need new glasses.
geekosaur or just a better font; ~ sucks in some of them
TimToady you just need one lens specialized for ~, and the other specialized for -
dha :-) 00:18
Actually, this is not the only reason I need new glasses, so I should really deal with that at some point...
timotimo deal with it at the focal point :) 00:19
timotimo disappears into the night
00:22 Peter_R left 00:27 laouji joined, BenGoldberg joined
TEttinger unifont remains very legible! 00:28
00:28 asdf12z_ left 00:29 vendethiel joined
geekosaur I always found unifont to be ugly as sin 00:30
japhb Just how ugly do you find sin to be? 00:36
ugexe m: my @bar = eager gather for 1,2,3 -> $i { my %foo; take { %foo }; %foo{$i} = $i; }; say @bar.perl
camelia rakudo-moar 4a7219: OUTPUT«[{}, {}, {}]<>␤»
ugexe darn 00:37
hoelzro m: sub foo:bar($/) { ... } 00:38
camelia rakudo-moar 4a7219: OUTPUT«5===SORRY!5=== Error while compiling /tmp/cgdyPA6dES␤Colon pair value '$/' too complex to use in name␤at /tmp/cgdyPA6dES:1␤------> 3sub foo:bar($/)7⏏5 { ... }␤»
hoelzro m: sub foo:bar ($/) { ... }
camelia ( no output )
hoelzro is that expected?
TEttinger geekosaur, ugly but clear at least. Inconsolate is quite pretty and I think is legible
*Inconsolata
00:39 mr-foobar left, laouji left
TEttinger www.fontsquirrel.com/fonts/Inconsolata but ~ and - remain very similar, especially at size 12 00:39
00:39 laouji joined
TimToady hoelzro: yes, pair notation, with a few exceptions, generally slurps up any following circumfixish chars 00:40
hoelzro TimToady: so longname methods need the space?
TimToady m: sub foo:bar[]($/) { ... }
camelia rakudo-moar 4a7219: OUTPUT«===SORRY!===␤Cannot find method 'ast'␤»
TimToady m: sub foo:bar()($/) { ... }
camelia rakudo-moar 4a7219: OUTPUT«===SORRY!===␤Cannot find method 'ast'␤»
TimToady hmm 00:41
geekosaur yeh, inconsolata's pretty good
TimToady m: sub foo:bar<>($/) { ... }
camelia rakudo-moar 4a7219: OUTPUT«5===SORRY!5===␤Null operator is not allowed␤at /tmp/NOQ3S2MrAv:1␤------> 3sub foo:bar<>7⏏5($/) { ... }␤Other potential difficulties:␤ Pair with <> really means an empty list, not null string; use :bar('') to represent the null string…»
TimToady heh
just use the space
00:41 laouji left
hoelzro you got it =) 00:42
TimToady m: sub foo:bar<x>($/) { ... } 00:43
camelia rakudo-moar 4a7219: OUTPUT«5===SORRY!5=== Error while compiling /tmp/soICC62wKA␤Cannot add tokens of category 'foo'␤at /tmp/soICC62wKA:1␤------> 3sub foo:bar<x>7⏏5($/) { ... }␤»
TimToady std: sub foo:bar<x>($/) { ... }
camelia std 28329a7: OUTPUT«ok 00:00 138m␤»
TimToady rakudo doesn't quite believe in pair-extended names the way std does
std: sub foo:bar<x>($/) { ... }; foo:bar<x>() 00:45
camelia std 28329a7: OUTPUT«5===SORRY!5===␤Undeclared routine:␤ 'foo:bar<x>' used at line 1␤Check failed␤FAILED 00:00 139m␤»
TimToady hmm 00:46
std: sub foo:bar<x> ($/) { ... }; foo:bar<x>()
camelia std 28329a7: OUTPUT«5===SORRY!5===␤Undeclared routine:␤ 'foo:bar<x>' used at line 1␤Check failed␤FAILED 00:00 139m␤»
TimToady interesting
std: sub foo:bar<x> ($/) { ... }; foo() 00:47
camelia std 28329a7: OUTPUT«5===SORRY!5===␤Undeclared routine:␤ 'foo' used at line 1␤Check failed␤FAILED 00:00 139m␤»
00:47 dha left
TimToady thinks that used to work better 00:47
flussence std: sub foo:bar<x> ($/) { ... }; bar()
camelia std 28329a7: OUTPUT«5===SORRY!5===␤Undeclared routine:␤ 'bar' used at line 1␤Check failed␤FAILED 00:00 139m␤»
00:48 captain-adequate left 00:50 laouji joined, vendethiel left 00:52 Akagi201 joined 00:54 tinyblak joined
skids m: sub a (:$a, :$b){ $a.say; $b.say }; my %f = (:a(0)); a(|%f, :b(1)); 00:56
camelia rakudo-moar 4a7219: OUTPUT«0␤1␤»
skids m: sub a (:$a, :$b){ $a.say; $b.say }; my %f = (:a(0)); a(:a(2), :a(3), :b(1));
camelia rakudo-moar 4a7219: OUTPUT«3␤1␤»
skids m: sub a (:$a, :$b){ $a.say; $b.say }; my %f = (:a(0)); a(|%f, :a(3), :b(1));
camelia rakudo-moar 4a7219: OUTPUT«Unexpected named parameter 'a' passed␤ in sub a at /tmp/0GpneSrcPJ:1␤ in block <unit> at /tmp/0GpneSrcPJ:1␤␤»
skids m: sub a (:$a, :$b){ $a.say; $b.say }; my %f = (:a(0)); a(:a(3), |%f, :b(1));
camelia rakudo-moar 4a7219: OUTPUT«Unexpected named parameter 'a' passed␤ in sub a at /tmp/07JVz0crLm:1␤ in block <unit> at /tmp/07JVz0crLm:1␤␤»
skids Oh hey someoe else noticed RT#77788 yesterday coincientally 00:59
synbot6 Link: rt.perl.org/rt3/Public/Bug/Display...l?id=77788
01:08 rmgk left, yeahnoob joined, mr-foobar joined 01:10 rmgk joined 01:14 raiph left, vendethiel joined, VinceDee left 01:21 yqt left
dalek osystem: 4b83f6c | (Sterling Hanenkamp)++ | META.list:
Adding ArrayHash to the ecosystem
01:27
01:29 raiph joined 01:32 dayangkun joined 01:35 atroxaper joined
skids zostay++ those will be useful. 01:38
(Though .push gets confusing given what Hash.push does in core.)
01:39 atroxaper left
zostay i tried to do something like the same 01:47
the operations are hashish or arrayish based upon the type of arguments
01:49 tinyblak left 01:50 aborazmeh joined, aborazmeh left, aborazmeh joined 01:54 tinyblak joined
skids Right, but Hash.push does this: 01:56
m: my %f = :b; %f.push((:b)); %f.say
camelia rakudo-moar 4a7219: OUTPUT«b => True True␤»
skids But also:
m: my %f = :b; %f.push(:b); %f.say 01:57
camelia rakudo-moar 4a7219: OUTPUT«b => True␤»
skids m: my %f = :b; %f.push(:b(1)); %f.say
camelia rakudo-moar 4a7219: OUTPUT«b => True␤»
skids ...does nothing with bare pairs as named args.
So maybe a better thing would be for ArrayHash.push to replace when given named parameters, and do what Hash.push does with positional pairs. 01:58
01:59 TimToady left, vendethiel left 02:00 TimToady joined 02:04 noganex_ joined
skids KnottyPairs are a nice clever little idea, too, BTW. 02:05
02:07 noganex left, vendethiel joined 02:12 geekosaur left, geekosaur joined 02:26 nys left 02:28 vendethiel left 02:31 nys joined 02:36 raiph left
zostay thx... i'm not sure how to copy with that... i don't fully understand all the ways in which pairs behave... they still seem strange to me at times 02:52
m: sub t(*@a, *%v) { @a.perl.say; %v.perl.say }; t("a" => 1); t(a => 1); 02:53
camelia rakudo-moar 4a7219: OUTPUT«[:a(1)]<>␤{}<>␤[]<>␤{:a(1)}<>␤»
zostay for example ^^^
s/copy/cope/ 02:54
anyway, definitely happy to entertain suggestions and patches
02:56 AlexDaniel left
skids zostay: that might be a bug, I dunno. 02:59
zostay sure, but i find the difference between (:b) and :b to be equally subtle and confusing even when i grok what's happening 03:01
=> as a constructor has some really interesting power, but there were some things that were nice about it just being a magic comma
03:14 raiph joined 03:15 aborazmeh left 03:17 tinyblak left 03:22 ShimmerFairy left 03:34 ShimmerFairy joined 03:37 nys left
raiph .tell masak jnthn, timtoady, froggs, on unbound names / interface consistency: gist.github.com/raiph/84050de6bb3decb69937 03:50
yoleaux raiph: I'll pass your message to masak.
03:51 atroxaper joined 03:53 laouji left 03:59 khw left
dalek kudo/nom: c8d1126 | (Nick Logan)++ | src/core/CompUnitRepo/Local/Installation.pm:
remove parrot /bin wrapper creation
04:10
kudo/nom: b35c39f | lizmat++ | src/core/CompUnitRepo/Local/Installation.pm:
Merge pull request #453 from ugexe/patch-3

remove parrot bin/ wrapper creation
04:17 dayangkun left 04:24 dayangkun joined, BenGoldberg left 04:28 tinyblak joined 04:29 dayangkun left 04:37 dayangkun joined 04:43 amurf joined 04:46 laouji joined 04:47 amurf left
dalek ar: 9e1b5fa | FROGGS++ | docs/announce/2015.06.md:
unmention JVM, too many modules fail
05:03
05:05 raiph left 05:06 kaare_ joined 05:18 vendethiel joined 05:20 aborazmeh joined, aborazmeh left, aborazmeh joined, aindilis left, aindilis joined 05:23 vendethiel left 05:24 vendethiel joined 05:25 gfldex joined, laouji left 05:26 laouji joined 05:31 quester joined 05:32 atroxaper left 05:36 Alina-malina left 05:37 Alina-malina joined 05:41 atroxaper joined 05:42 atroxaper left 05:43 atroxaper joined 05:46 Psyche^_ joined 05:50 Alina-malina left, Psyche^ left 06:02 aborazmeh left 06:06 |Tux| left, ][Sno][ left, skids left 06:07 |Tux| joined, FROGGS left 06:09 diana_olhovik_ joined, vendethiel left 06:14 vendethiel joined 06:17 Sqirrel left 06:22 [Sno] joined
masak morning, #perl6 06:30
yoleaux 03:50Z <raiph> masak: jnthn, timtoady, froggs, on unbound names / interface consistency: gist.github.com/raiph/84050de6bb3decb69937
masak reads that gist 06:31
clearly relevant for #perl6: elm-lang.org/blog/compiler-errors-for-humans -- HN discussion: news.ycombinator.com/item?id=9805978 06:32
06:33 Firedancer left
masak "It is kind of shocking how much better things get when you focus on the user." 06:33
06:36 vendethiel left, FROGGS joined 06:38 vendethiel joined
masak raiph: ok, both TimToady and FROGGS suggest throwing a warning in the backlog. I'm probably slow here, but isn't an implicit *%_ and then a warning kind of like inviting someone for dinner and then slapping them for taking food? 06:38
ShimmerFairy "color is a huge usability improvement." and yet their error messages look like walls of one color to me :P
masak raiph: I mean, if we're warning at the end, couldn't we just drop implicit *%_ altogether, and have the program die at bind-time instead? 06:39
FROGGS masak: warning about something is like deprecating that something.... I think I said that too in that context
masak right.
06:39 _mg_ joined
ShimmerFairy Good thing we have a deprecation warning setup, then :) 06:39
masak nonono 06:40
FROGGS masak: so *if* we warn, the implicit *%_ is just a thing that helps us to warn
masak *sigh*
I'm not getting through here.
FROGGS masak: and then we can think about removing the *%_ entirely
masak ok.
FROGGS but, I'm not sure either way
moritz masak: deprecation warnings are only for a transitional period
FROGGS I just see that *%_ seems to be confusing for some people
masak I think *%_ and then warning is literally the worst of all possible worlds. I hope we don't get stuck in that combination. 06:41
ShimmerFairy me too. *%_ should just not be there
masak implicit *%_ is a case of "ok, you thought about this carefully at the design stage. it just didn't end up being beneficial in the implementation." 06:42
moritz one could issue a deprecation warning when an implicit *%_ receives a value at run time
ShimmerFairy always finds the "interface consistency" funny when you consider subs never had *%_
06:42 mr-foobar left
ShimmerFairy *argument 06:42
06:45 atweiden joined
FROGGS moritz: that was also what we (bartolin and me) were thinking 06:48
like: "Gosh, we just dropped a named argument" 06:49
though, I don't think this will work out that nicely
we'll get false positives all over the place
masak false positives? 06:50
FROGGS we will warn too often 06:51
like, you add another named arg to class A, and class B, which A inherits from, warns about that extra arg for methods that B does 06:52
so you have to tell 'upstream' to change their code, which is crap
masak that's what interface consistency was meant to solve, no? 06:53
FROGGS exactly
masak "we can warn when people rely on the feature, but that will get in the way of people correctly relying on the feature"
why do I feel like there's no way to win in this scenario? 06:54
06:56 Ven joined
FROGGS I dunno, but I share that feeling 06:56
'guess we need a third option :o)
06:58 rindolf joined
atweiden hey guys, i am wondering if this is a gap in my knowledge or rakudobug 06:58
gist.github.com/atweiden/00aee14e2ed59471bb59 06:59
am trying to make copy of %wallet, then update the copy in place (%wllt). I use a scalar container explorer subroutine 'in_wallet' for this, then return the copy.
the subroutine 'in_wallet' appears to be updating both %wallet and the copy of %wallet (%wllt). i have tried passing %wallet 'is copy' with identical results
masak atweiden: yes, you're just copying the reference
that's generally true with objects
07:00 vendethiel left
atweiden hmm, i assumed i would need to use ':=' to point to the original class's container for that 07:02
how should i pass %wallet as a copy only? 'is readonly'?
07:02 FROGGS left
masak you need to make a new hash and put the entries from the old hash in the new hash 07:02
though an explicit .clone might work too 07:03
atweiden so does 'is copy' not work with objects? 07:04
masak basically not. it doesn't do what would be least-surprise.
atweiden eh, it makes some sense as i never instantiated a new wallet class. 07:05
masak bit tied up right npw 07:06
now*
might be able to help you more later
atweiden i think i have all the help i will need, it should be straight forward tyvm masak 07:07
07:08 Ven left 07:10 salv0 joined 07:15 tinyblak left 07:16 vendethiel joined
masak rest of channel: idiomatic way to clone a hash? 07:16
07:17 Ven joined
ShimmerFairy masak: my %newhash = gather for %oldhash { take $_ } ? 07:20
07:21 abraxxa joined, darutoko joined
Ven o/, #perl6 07:22
masak ShimmerFairy: useless use of gather ;)
ShimmerFairy: that's just `my %newhash = %oldhash`, at least pre-GLR
Ven: \o
07:24 zakharyas joined 07:30 dayangkun left
atweiden masak: appears to be working with for %wallet.kv -> $silo, $wallet { %wllt{::($silo)} = $wallet.clone; } 07:30
07:32 telex left, tinyblak joined 07:33 Psyche^_ left
JimmyZ my $newhash = %oldhash.clone? 07:33
07:33 Psyche^ joined
JimmyZ %newhash 07:33
07:34 telex joined 07:35 steve_mc joined 07:37 vendethiel left
Ven m: sub dynidx(@a, $n) { Proxy.new(FETCH => { @a[$n] }) }; my @a = 1, 2, 3; my $i = dynidx(@a, 1); say $i; @a[1] = 50; say $i; 07:40
camelia rakudo-moar b35c39: OUTPUT«2␤2␤»
Ven m: sub dynidx(@a, $n) { Proxy.new(FETCH => { @a[$n] }) }; my @a = 1, 2, 3; my $i := dynidx(@a, 1); say $i; @a[1] = 50; say $i;
camelia rakudo-moar b35c39: OUTPUT«2␤50␤»
Ven is reading blogs.perl.org/users/david_mertens/...erl-6.html
07:42 g4 joined, g4 left, g4 joined 07:43 RabidGravy joined 07:46 atroxaper left 07:48 quester left
RabidGravy morning 07:51
masak \o 07:52
07:56 dayangkun joined
ShimmerFairy I found a bug: 07:56
my @a = 1,2,3; my @b = 2,3,4; my @c = 3,5,7; my $Z; for (@a; @b; @c) { say $_ }
m: my @a = 1,2,3; my @b = 2,3,4; my @c = 3,5,7; my $Z; for (@a; @b; @c) { say $_ }
camelia rakudo-moar b35c39: OUTPUT«5===SORRY!5=== Error while compiling /tmp/QTu2xSaIiG␤Unsupported use of C-style "for (;;)" loop; in Perl 6 please use "loop (;;)"␤at /tmp/QTu2xSaIiG:1␤------> 3y @b = 2,3,4; my @c = 3,5,7; my $Z; for 7⏏5(@a; @b; @c) { say $_ }␤»
ShimmerFairy m: my @a = 1,2,3; my @b = 2,3,4; my @c = 3,5,7; my $Z; for (@a; @b) { say $_ }
camelia rakudo-moar b35c39: OUTPUT«1 2 3␤2 3 4␤»
masak notabug, methinks 07:57
ShimmerFairy How else should you compose a LoL in the for loop in this case? You can put a ; after @c as a workaround, at least
[@a; @b; @c], which would've been my guess for another way of doing it, doesn't actually work 07:58
07:59 domidumont joined
ShimmerFairy m: my @a = 1,2,3; my @b = 2,3,4; my @c = 3,5,7; my $Z; for ((@a; @b; @c)) { say $_ } 08:00
camelia rakudo-moar b35c39: OUTPUT«1 2 3␤2 3 4␤3 5 7␤»
ShimmerFairy ^ another workaround
08:00 atroxaper joined 08:03 domidumont left 08:04 domidumont joined, abraxxa1 joined 08:07 abraxxa left
ShimmerFairy m: say "AAA" ~~ / $<letter>=(A)**3 /; say "AAA" ~~ / $<letter>=(A)**{3} / 08:13
camelia rakudo-moar b35c39: OUTPUT«「AAA」␤ letter => 「A」␤ letter => 「A」␤ letter => 「A」␤「AAA」␤ letter => 「AAA」␤»
ShimmerFairy What's with the different behavior here? In code, I'm using a dynamic variable, which demands the **{} form, though I want the result you get from bare ** (as well as from a simple + quantifier) 08:14
masak ShimmerFairy: that does look like a bug. please submit, kthx.
ShimmerFairy just for reference to another quantifier: 08:15
m: say "AAA" ~~ / $<letter>=(A)+ /;
camelia rakudo-moar b35c39: OUTPUT«「AAA」␤ letter => 「A」␤ letter => 「A」␤ letter => 「A」␤»
ShimmerFairy masak: OK, I wasn't sure if there was some hidden super-good reason for it :P 08:16
masak not that I'm aware
08:16 dakkar joined 08:18 rindolf left 08:20 amurf joined
Ven blog.travis-ci.com/2015-06-30-cryst...travis-ci/ ooh, that's great to hear :) 08:21
ShimmerFairy masak: rakudobug'd :) 08:22
masak: btw, do you happen to know why (thing)**$*VARIABLE doesn't work, and you need the braces around $*VARIABLE? 08:23
08:24 Alina-malina joined 08:25 amurf left, domidumont left
masak ShimmerFairy++ 08:29
ShimmerFairy: historical raisins.
ShimmerFairy: `x ** y` used to also cover the semantic space that `x +% y` now covers. that is the `y` could be a string. 08:30
or a piece of regex.
jnthn morning, #perl6
masak the braces are there to catch some of these old thinkos.
not entirely sure it's still needed -- probably everyone has upgraded now. 08:31
jnthn: mornin'
Ulti /win 2 08:32
erk
jnthn
.oO( /fail 2 )
08:33
ShimmerFairy masak: to be fair, **$*VAR looks like you're doing something suspicious, when out of context :P 08:34
masak ShimmerFairy: well, you should usually put in the spaces, unless you're constrained by :s 08:35
ShimmerFairy masak: for whatever reason, I don't typically put space between the quantifier and the information it uses (so atom+ atom* atom? atom**3) 08:36
08:36 tinyblak left 08:41 laouji left, laouji joined 08:44 CharellKing joined
RabidGravy today starts with more dicking around with a twenty year old P5 module 08:45
jnthn Damn, that's probably older than some people on this channel... :) 08:48
masak ShimmerFairy: I think the difference (for me) is that `**` is an infix operator, and so I tend to put in the spaces. not so for the three postfixes `+*?` 08:51
08:53 tinyblak joined
ShimmerFairy masak: fair enough, I think when I first learned of ** my mind simply saw it as another quantifier, and decided on the whitespace conventions to match :) 08:54
masak never too late to change ;)
it *is* another quantifier. just an infix one.
jnthn We don't really parse it as an infix, iirc. 08:57
masak in that case, the regex slang has to have special postfix parsing 08:59
well, it has to anyway
since you can `a +`
masak .oO( it's a "postfix with benefits" )
RabidGravy |Tux|, you're an HP-UX type of guy aren't you? Got a minute to test Term::Cap to see if an injudicious merge has been un-done? 09:02
09:03 Alina-malina left
masak .oO( "You're an HP-UX type of guy, aren't you? Find your perfect match here! [link]" ) 09:03
|Tux| :) 09:04
RabidGravy, do you want your own HP-UX account?
RabidGravy Oooooh 09:05
yeah that would be cool, I can banish this forever then ;-)
|Tux| see private dialog 09:06
jnthn m: my @a = [1,2],[3,4]; say @a[0;0] 09:09
camelia rakudo-moar b35c39: OUTPUT«1␤»
jnthn m: my @a = [1,2],[3,4]; my @x = 0,0; say @a[|@x]
camelia rakudo-moar b35c39: OUTPUT«5===SORRY!5=== Error while compiling /tmp/n8J7z8KgOo␤Arg-flattening | is only valid in an argument list␤at /tmp/n8J7z8KgOo:1␤------> 3 @a = [1,2],[3,4]; my @x = 0,0; say @a[|7⏏5@x]␤»
jnthn m: my @a = [1,2],[3,4]; my @x = 0,0; say @a[||@x] 09:10
camelia rakudo-moar b35c39: OUTPUT«5===SORRY!5===␤Arg-flattening | is only valid in an argument list␤at /tmp/a8P4TFhoQw:1␤------> 3 @a = [1,2],[3,4]; my @x = 0,0; say @a[|7⏏5|@x]␤Arg-flattening | is only valid in an argument list␤at /tmp/a8P4TFhoQw:1␤------> 3@a = [1,…»
jnthn m: my @a = [1,2],[3,4]; my @x = 0,0; say postcircumfix:<[ ]>(@a, |@x)
camelia rakudo-moar b35c39: OUTPUT«0␤»
jnthn m: my @a = [1,2],[3,4]; my @x = 0,0; say postcircumfix:<[ ]>(@a, ||@x)
camelia rakudo-moar b35c39: OUTPUT«5===SORRY!5=== Error while compiling /tmp/KdPkoouMHc␤Variable '&prefix:<|>' is not declared␤at /tmp/KdPkoouMHc:1␤------> 3 @x = 0,0; say postcircumfix:<[ ]>(@a, |7⏏5|@x)␤»
jnthn m: :x(3,3,3) 09:13
camelia ( no output )
jnthn m: :x(3,3,3).perl.say
camelia rakudo-moar b35c39: OUTPUT«:x($(3, 3, 3))␤»
jnthn m: :x(3;3;3).perl.say
camelia rakudo-moar b35c39: OUTPUT«:x((3; 3; 3).item)␤»
09:13 espadrine joined 09:16 atroxaper left 09:18 sjn_phone joined, mr-foobar joined 09:25 tinyblak left
jnthn .tell TimToady Was going through S09 in prep for working on multi-dim stuff and spotted various things that seem a little off or in need of review/decisions: gist.github.com/jnthn/fa6a9a3618ae322cb581 09:26
yoleaux jnthn: I'll pass your message to TimToady.
09:38 atroxaper joined
Ulti can I make an argument for .Bag on Str to be more like Str.comb.Bag? 09:41
09:41 Ven left
Ulti kind of unlikely when someone calls bag on a string they meant a bag with nothing in apart from the string :/ not entirely sure when that would ever be useful? 09:42
09:43 |Tux| left
Ulti m: say "hello".Bag 09:43
camelia rakudo-moar b35c39: OUTPUT«bag(hello)␤»
Ulti m: say "hello".comb.Bag
camelia rakudo-moar b35c39: OUTPUT«bag(l(2), e, h, o)␤»
09:44 cognominal left 09:45 sjn_phone_ joined
Ulti if you wanted a bag with just the string in you could still do bag("hello") 09:46
09:47 sjn_phone left 09:48 sjn_phone joined, smls joined 09:49 sjn_phone_ left 09:50 |Tux| joined
smls would post a comment on run4flat's blog, but it looks like the login/comment system on blogs.perl.org is utterly borked... :( 09:53
DrForr I just posted something last night, it seemed to work. 09:54
09:55 |Tux| left
smls strange 09:55
09:55 |Tux| joined, atroxaper left
smls looks like I'm not the only one for whom it's broken: github.com/blogs-perl-org/blogs.pe...issues/294 09:57
09:58 atroxaper joined 09:59 yeahnoob left 10:00 atweiden left, abraxxa1 left 10:04 abraxxa joined
RabidGravy |Tux|++ # he's the man with the HP-UX plan! 10:06
10:10 amurf joined 10:14 amurf left
smls DrForr: Could you post a comment to blogs.perl.org/users/david_mertens/...erl-6.html for me, with a link to smls2.wordpress.com/2015/07/01/re-...in-perl-6/ ? 10:15
DrForr Uh, not today :/ I guess this is the issue we're talking about. 10:16
10:16 _mg_ left
smls heh 10:17
DrForr Even after logging in. 10:18
10:18 gtodd left
DrForr I don't know how much I can say about this, but I can tell you these issues are being worked on. 10:18
10:19 domidumont joined, domidumont left 10:20 domidumont joined 10:23 VinceDee joined 10:24 CharellKing left 10:26 iH2O joined, tinyblak joined 10:31 iH2O left, tinyblak left, Akagi201 left 10:32 Akagi201 joined, tinyblak joined 10:34 CharellKing joined 10:35 RabidGravy left 10:36 dayangkun left, Akagi201 left 10:39 abraxxa left 10:45 |Tux| left, |Tux| joined 10:46 _mg_ joined 10:49 tinyblak left 10:51 TEttinger left 10:53 Ven joined 10:56 Ven_ joined, abraxxa joined, rindolf joined 10:58 Ven left 10:59 RabidGravy joined, Ven_ left
RabidGravy there 10:59
11:03 atroxaper left
DrForr Nailed it? 11:03
(whatever 'it' is...)
RabidGravy nope, just rebooted laptop due to "new kernel"
11:03 domidumont left
DrForr linode+irssi+screen = never having to say /quit :) 11:04
RabidGravy I remember them olden days when it took the Linux kernel ten years to go from 1 to 2, it appears to have go 3 -> 4+ in less than a year
11:05 tinyblak joined 11:06 Alina-malina joined 11:10 spintronic left, spintronic joined 11:12 atroxaper joined
smls DrForr: I managed to post a comment on blogs.perl.org after all, by logging in via OpenID using "openid.stackexchange.com" 11:15
11:19 RabidGravy left, Ven joined 11:24 sjn_phone left 11:27 smls left
masak just throwing this out there, since I'm thinking about it currently: for something like `my {{{$new-identifier}}};` or `sub foo({{{$param}}})` to work inside a quasi, these unquotes need to be sure they are getting an AST of the right type. maybe unquotes should require their content to be statically typed? 11:41
11:51 |Tux| left, Tux__ joined
ShimmerFairy masak: I think you caught this before, but I brought forth the idea that macros are "$thing generators", where $thing is a variety of things (variable, function, class, and so on), and if macros could maybe benefit from specifying what they generate. 11:55
I can certainly see unquotes benefiting from the same kind of thing, maybe.
11:55 Ven left
masak I've yet to think of a case where it's absolutely necessary. the crucial thing is, of course, that the parser knows exactly what to expect next after it's parsed an unquote. 11:56
maybe something like `sub foo({{{$param}}})` vs `sub foo({{{$paramlist}}})` 11:57
in the former case, it's ok to insert a comma after the unquote. in the latter case not.
ShimmerFairy How would the parser usually differentiate the two? Or is that an example of something that can only happen in macroland? 11:58
masak it's an example of something that can only happen with unquotes
because usually the parser has all of the program text available at parse time, without holes
but quasis say "here, parse these known things. ignore the holes for now." which is fine, but the parser needs to be sure what "parsing state" it's in at all times, especially after an unquote. 11:59
ShimmerFairy Hmm... how difficult would it be to twist this around, so instead of "how can the parser know what to get next?", it's "what can the parser allow here?", and then the fault lies with the unquoted thing instead of the surrounding text. 12:00
masak oh, sure.
my point is that there can be *no* ambiguity about the parser state. and I'm not sure that's acheivable without requiring that the (Qtree) type of the thing in the unquotes be statically known, at least in some cases. 12:01
12:02 RabidGravy joined
RabidGravy now that was somewhat of an unscheduled reboot 12:02
12:02 CharellKing left
masak TimToady++ keeps reminding us that the parser must always know what language it's parsing. this falls under that. the parser is not allowed to be in an ambiguous state. 12:02
12:04 iH2O joined
ShimmerFairy I'm fine with macros being a bit more static than the rest of Perl 6, if that turns out to be the better solution. (In fact, my earlier suggestion about specifying the macro's "type" probably stems from thinking in too much of C++-ish way :P) 12:04
masak this whole line of thinking stems from me starting to think seriously about unquotes in non-EXPR positions. 12:05
iH2O I have the latest Rakudo Moar untared in /root/.perl6/2015.06 and was trying to compile it with this as usual:
masak which we'll probably see implemented in 007 before Rakudo.
ShimmerFairy
.oO( sub foo({{{paramlist}{$stuff}}}) , to make the triple-braces even worse)
iH2O perl Configure.pl --backend=moar --gen-moar
make
make install
make rakudo-test
but "make" fails :( pastebin.com/4f3z3P98
masak ShimmerFairy: ick. no. :) 12:06
ShimmerFairy: took me a while to even parse that in my head.
iH2O: looking.
ShimmerFairy masak: Suddenly my mind is trying to analogize an english workbook sort of thing, where you have example sentences with blank lines where you need to fill in the right thing. I wonder how helpful that framing could be (probably not very) 12:07
masak iH2O: huh. curious.
iH2O: all I can say so far is "it shouldn't fail like that".
iH2O I should say I have an old distro
masak shouldn't matter, really. 12:08
iH2O all previous Rakudo versions compiled fine on my distro
jnthn That's an odd place to fail too...I mean, it almost got right to the end...
12:08 cognominal joined
jnthn iH2O: Could you try running the last step manually, but add the option "--ll-exception"? 12:09
masak jnthn++ # helping iH2O
iH2O yes, I'll be back...
I have to reboot...
12:10 iH2O left
ShimmerFairy masak: I want to say you could maybe check the type of the expression appropriately, like making sure $thing in {{{$thing}}} is of type QParamList, before moving on in parsing. But depending on how complex expressions can get in unquotes, that might not be feasible. 12:12
masak ShimmerFairy: onus is on the macro author not to make the expression in the unquote so complex as to be uncheckable. 12:13
ShimmerFairy: like, maybe we only allow a single (statically typed) variable.
which is not really a limitation because you can still initialize that variable however you want.
ShimmerFairy masak: I think moving all the work outside of the quasi would be good practice regardless 12:14
masak right; keep the unquotes small. 12:15
maybe we could even mandate that on the parse level. an unquote has to look like {{{$foo}}}
(for any variable $foo) 12:16
ShimmerFairy I don't know if you want to allow other sigils and twigils too :)
12:16 domidumont joined
ShimmerFairy masak: would checking the .WHAT of the variable (however that's actually done in the parsing) allow for more freedom than just static typing, or would that not be a considerable improvement on what you can do? 12:17
masak the only optional I can think of that makes sense is sigilless (backslash variables and constants)
but hey, if someone can make it work with @foo or &foo (and can get past the type checking), then be my guest. 12:18
like, maybe @params makes sense for a paramlist
RabidGravy computer really not happy with this heat, may have to get some active cooling going 12:19
ShimmerFairy masak: I'm thinking $var, @var[index-not-slice], %var{key} should be allowed, if the parser is super-strict about the syntax. And maaaaaaybe {{{@foo}}} -> {{{@foo[0]}}}{{{@foo[1]}}}...
masak ShimmerFairy: recall that "checking the .WHAT" happens at runtime, long after the parse. so that's a no-go.
ShimmerFairy ah, so there's no .WHAT-like info available at parse time then? Darn, I guess I'll have to live static typing, such a tragedy. :P 12:20
jnthn masak: The alternative I guess is a syntax that makes people spell out the grammatical category if it's not a term.
ShimmerFairy masak: I also realized, depending on how you name the QTree types, our macros might be mistaken for Qt Code :) .oO(my QFunction $foo; ...) 12:21
masak ShimmerFairy: you're right, we can't disallow indexing. that's too useful.
ShimmerFairy: fortunately, array/hash elements can be easily type-declared too :>
jnthn {{{|postfix| $foo}}} 12:22
ShimmerFairy masak: basically, "what does qq// allow for interpolation without requiring braces" is my line of thought
masak jnthn: right. TimToady++ has been playing around with such ideas.
ShimmerFairy jnthn: I came up with {{{postfix}{$foo}}} >:)
masak ShimmerFairy: the Qtree types will end up having names like Q::Given
jnthn I can see how to get that idea to work with the grammar...
More easily than the type one
ShimmerFairy Alternatively, since everybody wants the colon: {{{postfix: $foo}}}
masak jnthn: ok, good to know. 12:23
ShimmerFairy: nice
ShimmerFairy: now if we could only get rid of the {{{ }}} :)
jnthn Because we could actually register a postfix in the LTM-er that has {{{postfix} as the LTM prefix.
masak I've been thinking about stealing backticks
ShimmerFairy masak: it would provide nice symmetry with sub postfix:<stuff> , incidentally
masak `postfix $foo`
ShimmerFairy (well, kinda-symmetry)
masak and maybe 'expr' should be the default: `expr $bar` same as `$bar` 12:24
12:24 AlexDaniel joined
jnthn And if we can get the syntax to just be an extra entry into the token table, or at least give it a fixed prefix that will be, then it's not too hard. 12:24
masak or maybe the default should depend on the parsing context.
jnthn Hm, I'd thought term would be the default :) 12:25
ShimmerFairy masak: I like the use of backticks. I think inserting code in place of text is nicely similar to the shell's "command in place of arguments" :)