»ö« | perl6-projects.org/ | nopaste: sial.org/pbot/perl6 | evalbot: 'perl6: say 3;' | irclog: irc.pugscode.org/ | UTF-8 is your friend!
Set by Tene on 14 May 2009.
00:01 DemoFreak left 00:02 icwiener_ left, pina left 00:15 fridim_ left 00:18 frew joined 00:33 CMA left 00:41 CMA joined 00:44 icwiener-_- left 00:53 wknight8111 joined 00:54 Whiteknight left 00:55 JDlugosz joined
JDlugosz Well, I just found The Periodic Table of Perl 6 Operators. Thanks, Larry. I'll print it out large and hang it at work, where I was just saying I need something other than bare wall. 00:59
literal Larry didn't make it :) 01:00
JDlugosz Back to iterator .get and .lines ⇰ Why two separate commands? As opposed to one, that is. 01:01
TimToady different return type
JDlugosz Literal: Yes, I know. He pointed it out to me earlier today. I see it is made by markl.
TimToady .lines always returns a list, .get always returns an item 01:03
so .get is equivalent to .lines(1)[0]
JDlugosz Sounds too traditional, like something you'd find in Java. Why getting away from context?
meppl good night
TimToady when it makes sense, we return a capture, which does the right thing in context 01:04
but in this case, it seems better to split the concepts
however, for an example we decided the other way
there's .pick vs .pick(3) 01:05
01:05 meppl left
JDlugosz Speaking of returning... 01:05
TimToady .pick returns a capture containing a single item, which behaves as an item in context and doesn't need .[0]
JDlugosz A while back I wrote <www.dlugosz.com/Perl6/web/return.html> which was apparently well-received. ... 01:06
But, meanwhile, still wondered how to *declare* a function with strong typing that returned one thing or another based on context. ... 01:07
Now I wonder what is the point of returning a Capture to defer that decision. You will populate it with the same stuff regardless of the context. And $ operator on Context has been removed from S02. 01:08
Another quick one : I see constants named True and False, initial capped, in S02 now. Why cap? Not a type name. 01:11
TimToady they're enums
and they're types insofar as any subtype is a type 01:12
enums and constants are just types of one value
(well, that's one view of it :)
anyway, named values parse as types
meaning they never look for a following arglist 01:13
01:13 cspencer left
TimToady they may or may not respond to an explicit .() 01:13
so all coercions are types responding to .(), as in Str()
01:13 cspencer joined 01:14 cspencer left
JDlugosz So, for similarities in the parser, any sigil-less named value other than subs are capitalized? 01:14
TimToady they don't have to be, it's just customary to reserved lowercase typenames for native types
JDlugosz I mean your current convention. 01:15
Built-in constants and standard library constants will be capitalized?
TimToady well, the common examples tend to be Sun,Mon,Tue, and such :)
not all of them
rakudo: say pi 01:16
p6eval rakudo ec55f1: OUTPUT«3.14159265358979␤»
TimToady rakudo: say e
p6eval rakudo ec55f1: OUTPUT«2.71828182845905␤»
TimToady std: say pi
p6eval std 26860: OUTPUT«ok 00:02 35m␤»
TimToady std: say pi()
p6eval std 26860: OUTPUT«Undeclared routine:␤ pi used at 1 ␤ok 00:02 35m␤»
01:16 bacek_ joined
TimToady note constants are not considered functions, unlike in p5 01:16
pi is more like Tue 01:17
JDlugosz Enums in particular? You felt a deep connection with enumerations as single-value subtypes? Or just your whim for True, or for consistancy with things like Tue?
Yes, I recall that constants are variables, but can be declared with a sigil for items. 01:18
TimToady basically any value can be used as a single-valued type in a signature
we can now leave the sigil off constants
std: constant answer = 42;
p6eval std 26860: OUTPUT«ok 00:02 35m␤»
JDlugosz in a signature .... ah, so by making them subtypes, you can directly use them for MMD constraints?
01:18 bacek left
TimToady yes, and write the usual factorial with multi factorial (0) { 1 } etc 01:19
JDlugosz Yes, I know you can declare a constant with or without a sigil. It's been that way as long as I can remember.
TimToady uh, specced, but STD didn't implement it till a month ago or so (hides head in shame)
s/implement/parse
JDlugosz The number 0, too? That used to not be the case. If you allow any single value in MMD, you don't need to make enums special. 01:20
TimToady it's just useful to classify named values with types for parsing purposes
JDlugosz I do like it. I was afraid of having standard subtypes for things like Zero just to do that.
TimToady and we might get more mileage out of it as we go along 01:21
it just seems like a single value is a degenerate case of a subset type
JDlugosz If any constant or literal will do -- why not? Define it as being an auto-generated subtype of one item. Also have to make sure identically "declared" subtypes are the same type.
I like it. It fixes a hole I've perceved before. 01:22
How about the Capture thing?
TimToady I don't see it as returning a Capture if it knows what type it's declared to return 01:23
it just returns that
JDlugosz You mentioned earlier about some things returning captures "which does the right thing in context", re scalar vs list. 01:24
It looks like, in S02, that the list (perl 5 [...] syntax) is now a capture. So maybe you just meant that? A list that becomes just its first item in item context?
TimToady yes, if you say return 1 you can use the return value as a scalar even though it's the first positional
Captures no longer distinguish an invocant separate from the first positional 01:25
JDlugosz That's the gist I got from the diff of S02. Invokant is no longer special that way, and $ operator no longer works on Capture. 01:26
TimToady it no longer works in the way it did
it can still treat a single positional as an item, but other than that, a Capture in scalar context is just itself 01:27
JDlugosz But... my model of the 'return' formalism (see link) is that the return Capture is automatically dereferenced in context. You removed $ operator on Capture from S02.
TimToady s/scalar/item/
I suspect ruoso can explain this better than I can, especially since I'm being called to dinner... 01:28
(if he's around)
JDlugosz Maybe he'll notice this in the log. 01:29
TimToady ruoso: ^^^ 01:30
JDlugosz ruoso: ^^^
(echo in here)
TimToady well later, hope this helps
dinner &
JDlugosz Thanks.
01:45 justatheory joined 01:49 cspencer joined
JDlugosz Question on complex numbers and/or the "\" character ⇰ In S02 it says "The complex type defaults to NaN + NaN\i." What is the use of i here, syntactically? 01:49
01:55 agentzh joined
ruoso JDlugosz, the idea is that Capture does both .[] and .{}, so if there is more than one item (positional or named) it will be available as if it was a hash or an array... but in the "return 1" case, the capture in item context will return that parameter for DWIM sake 01:58
so basically if you're doing "return 1,2,3" and use that value as a list, you'll be able to use @foo[0] 02:01
if you assign it to a scalar, you'll still be able to use $foo[0]
and as a hash, you (surprisingly) will still be able to use %foo[0] 02:02
std: sub foo { return 1,2,3 }; my %a = foo(); say %a[0];
p6eval std 26860: OUTPUT«ok 00:02 37m␤»
JDlugosz So, given sub foo { return 1 }
$x = foo;
What does the item $x contain?
ruoso this is the only exception... $x will be 1
JDlugosz exception??? 02:03
ruoso in every other case, $x will contain the capture itself
JDlugosz What's wrong with saying that the returned Capture is automatically dereferenced in item context.
ruoso because the capture is not a reference
JDlugosz ?
ruoso the analogy with p5 is not precise
JDlugosz So you prevent it just so it doesn't look too much like a p5 ref? 02:04
02:04 justatheory left
ruoso I'm not sure what you mean... 02:04
JDlugosz I mean I know it's not the same as a ref. Why did the scalar dereference go away? 02:05
ruoso when you do return 1,2,3 you don't have a "reference" to a "list" that gets "dereferenced" when you assign to a list
JDlugosz Whatever you call it. I could argue that terminology, but whatever.
ruoso the scalar dereference gone away because in Perl 6 you have a clear distinction between the container and the value 02:06
which you didn't in p5
rakudo: my $a = 1; say VAR($a).WHAT;
p6eval rakudo ec55f1: OUTPUT«Int()␤»
JDlugosz Using the @ operator on a Capture will produce a list.
ruoso no... it will return the capture itself 02:07
which happens to implement the list api
JDlugosz OK.
ruoso btw... rakudo failed in the eval I just did
JDlugosz So it's now pointless to use @ or % operators on a Capture. Even though they are mentioned in S-2.
ruoso pugs: my $a = 1; say VAR($a).WHAT
p6eval pugs: OUTPUT«Int␤»
02:07 eternaleye left
ruoso gah... pugs also failed 02:07
02:08 eternaleye_ joined
ruoso JDlugosz, it's pretty much pointless, yes... 02:08
what you need to realize, otoh, is the difference between 02:09
my @a = foo();
my @a := foo()
my @a <== foo();
JDlugosz I would expect a variable defined as Int to be an item container that only holds Ints.
ruoso yeah... but the variable is not declared that way... the result was supposed to be "Scalar"
JDlugosz OK, the first defines an Array container that is populated with the return from foo. OK, the Capture makes sense there. 02:10
The second binds a variable to the Capture as the container implementing the Positional role.
I'm not familiar with the 3rd.
02:10 cspencer left, cspencer joined
ruoso JDlugosz, it will, in a "mostly lazy" way, populate @a with the result from foo() 02:10
with implicit threading 02:11
02:11 jferrero left
ruoso the difference between that and the first is that the first is "mostly eager" 02:11
JDlugosz But given my $x = @a; that will make the item container hold the container bound to @a.
Right? 02:12
I avoided the word "reference".
ruoso rakudo: my @a = 1,2,3; my $x = @a; $x[0] = 4; say @a; 02:13
p6eval rakudo ec55f1: OUTPUT«423␤»
JDlugosz and my Int $x = @a; would be an error, because an Array (or whatever) isn't an Int.
ruoso it's not really about the container itself
JDlugosz it ? 02:14
ruoso what happens in $x = @a is "take the thing you find by the name '@a' and call .item on it, then store on the scalar that you find by the name '$x'"
the rvalue here could be anything 02:15
it's not the language that is handling that, it's @a itself
so if your @a implements a different coercion to item
it will return something different
JDlugosz Is that relativily new? 02:16
ruoso not at all... that is the basic concept
JDlugosz The Synopses didn't say that last time I read in detail (about 8 months ago) 02:17
ruoso rakudo: class Foo { method postcircumfix:<[ ]> ($index) { return $index * 2 }; method item { return 'foo' } }; my @a := Foo.new; say @a[100]; my $x = @a; say $x;
p6eval rakudo ec55f1: OUTPUT«elements() not implemented in class 'Foo'␤»
ruoso pugs: class Foo { method postcircumfix:<[ ]> ($index) { return $index * 2 }; method item { return 'foo' } }; my @a := Foo.new; say @a[100]; my $x = @a; say $x;
p6eval pugs: OUTPUT«␤<obj:Foo>␤»
ruoso gah... they're both wrong 02:18
JDlugosz But lets elaborate on that. $x = @a, not counting any knowledge of the built-in default meanings of default things, says to call .item on the container bound to @a, and STORE the result IN the container that's bound to $x. Right? 02:19
ruoso yes 02:20
JDlugosz Meanwhile, how is .item() method different from using $ as a prefix operator?
ruoso it isn't
it's basically the same thing
JDlugosz Then why isn't it available on Capture anymore, especially given that's the key to what happens when you call $x=foo ? 02:21
ruoso rakudo: class Foo { method postcircumfix:<[ ]> ($index) { return $index * 2 }; method item { return 'foo' } }; my @a := Foo.new; say @a[100]; sub bla { @a }; my $x = bla(); say $x; #
p6eval rakudo ec55f1: OUTPUT«elements() not implemented in class 'Foo'␤»
ruoso JDlugosz, operators are not methods
operators are multi subs
I'm quite sure that the default implementation of prefix:<$> is to call .item
JDlugosz Agreed.
And what happens when you say $x=foo() ? The .item() method is called on the Capture returned from foo? 02:22
ruoso exactly
(in smop that is still spelled FETCH 02:23
(i'm not very confortable with .item, very easy to clash with other things...)
JDlugosz So, why was prefix $ removed from something defined with Capture ?
ruoso it was removed from the spec as something that would have a special meaning
JDlugosz I agree, we need a different syntax for coersion operators. But that's detail. Lets get the concepts right.
ruoso std: sub foo { }; my $x = $(foo()); 02:24
p6eval std 26860: OUTPUT«ok 00:02 36m␤»
JDlugosz So @ on a Capture is "special" in that it doesn't just apply the ARRAY operator?
ruoso it try to coerce to a list, yes 02:25
but in a capture, coercing to List means returning the capture itself
since the capture itself implements the list api already
JDlugosz I don't follow your last execution example.
ruoso the prefix $ is there
noone removed it
JDlugosz I did a diff, and the examples and explainations were systematically removed. 02:26
ruoso because it's no longer important in the concept of the Capture
specially because "my $x = $(foo())" is pointless
JDlugosz Look for "you can retrieve parts from a Capture object with a prefix sigil operator..." 02:27
ruoso since you're already implying the context by the assignment
JDlugosz $args = \( whatever ); 02:28
02:28 lichtkind_ left
JDlugosz $$args is removed from S02. 02:28
ruoso because $$args is probably going to get you the same as $args
JDlugosz Implying it no longer "retrieves parts".
ruoso exactly...
JDlugosz But then we are back to $x=foo not working. 02:29
ruoso there's *one* exception
(which is documented in the spec somewhere)
JDlugosz $x wants to contain the first (only) value in the Capture, not the Capture itself.
ruoso If the capture contains only one argument (positional or named), it will return that when used in item context
02:30 sri_kraih_ joined
ruoso so... 02:30
sub foo { return 1 }; my $x = foo();
$x contains an Int
sub foo { return 1,2,3 }; my $x = foo();
$x contains a Capture
sub foo { return a => 1 }; my $x = foo();
$x contains a Pair
JDlugosz So, .item (or whatever it will be eventually called), aka prefix operator $, on a Capture will return the item if it contains exactly one positional item, or the Capture itself (identity) otherwise.
Is that it?
ruoso exactly 02:31
that's the DWIM exception
JDlugosz Could have just said so.
ruoso that's what I'm trying to say
;)
JDlugosz Yea. DWIM does not a formal specification make.
ruoso recalls that being spec already... 02:32
JDlugosz So you never commented on my write-up in Perl 6 Language to say it was all wet, about a year ago.
Ah, but the wording in S02 etc. was changed since then.
When was this all hashed out?
I see a trend toward Captures being more and more central to the plot, as they are understood. 02:33
It used to be that the Scalar context was linked to the invocant.
I can see this way, getting rid of implied dereference in a particular case, it better. 02:34
ruoso the change in Capture is fairly recent 02:35
we're just finishing a huge refactroing in SMOP because of that change
JDlugosz OK. So I'd better make sure I "get it". 02:36
And then I might fix the rough edits from S02 et al.
ruoso basically, Capture is no longer an unstable object 02:37
(since it was destructive too easily)
JDlugosz Well, maybe my write-ups were of some good after all.
Did I also read that [...] is no longer a List, but a Capture ?
ruoso oh... certainly... I had to pester TimToady a lot until he had the change... 02:38
about [...], where are you reading? (line if possible)
JDlugosz I can't find it...just my notes. 02:39
Was in S02, looking at the Unified Diff.
ruoso I think [...] is still an array constructor
JDlugosz Let me figure it out based on what's around it...
ruoso and (...) is a capture constructor
while the prefix \ means "enclose this capture in a scalar"
02:40 dduncan joined, dduncan left
ruoso but with the latest changes, you have fewer reasons to use prefix \ 02:40
JDlugosz Nope, can't find it.
Can you give example? 02:41
ruoso my $x = (1,2,3) vs my $x = \(1,2,3)
the \ is useless there
but...
my $x = \foo()
makes sure your capture don't get destroyed by the DWIM case 02:42
JDlugosz Maybe that's what I saw, (), not []. The () alone now does it. The \ adds a wrapper so the single value doesn't pop out again (the special case).
ruoso yes
JDlugosz OK. Time for another question? I think this is a typo in S02. 02:43
ruoso shoot
JDlugosz “Therefore @array[^**] represents @array[{ map { ^* }, @_ }], that is to say, every element of the array, no matter how many dimensions.”
ruoso that's really two * 02:44
JDlugosz I don't like the ^**. I think it should be [^]**. Or, is ^ applied to a list automatically hypered?
I know ** is multi-dimensional Whatever.
ruoso getting the context around the quote
JDlugosz The question is on applying ^ to a list. 02:45
02:45 sri_kraih left
ruoso JDlugosz, the closest you'd get would be ^(**) 02:48
std: my @a; @a[^(**) ];
p6eval std 26860: OUTPUT«ok 00:02 38m␤»
ruoso because the operator is ^, and the value is ** 02:49
rakudo: my @a = [1,2,3],[4,5,6],[7,8,8 02:50
JDlugosz or ^\**, to separate the tokens with a degenerate unspace.
ruoso gah
p6eval rakudo ec55f1: OUTPUT«Statement not terminated properly at line 1, near "[7,8,8"␤in Main (src/gen_setting.pm:0)␤»
ruoso rakudo: my @a = [1,2,3],[4,5,6],[7,8,9]; say @a[^**];
p6eval rakudo ec55f1: OUTPUT«Statement not terminated properly at line 1, near "[^**];"␤in Main (src/gen_setting.pm:0)␤»
ruoso ok... rakudo doesn't support it already 02:51
std: my @a; @a[^\**];
p6eval std 26860: OUTPUT«ok 00:02 38m␤»
JDlugosz So, ^ DOES work on a list without needing to hyper-ize it?
But it's wrong in another way, tokens run together ?
ruoso the spec says it's translated to a map 02:52
so I guess it's not as an hyperoperator
so no concurrent execution
JDlugosz I think that's a quibble.
No reason it couldn't be concurrent. Just no "other" and "Perl 5 familiar" way to write that. 02:53
ruoso maybe the expanded example is just an example...
but TimToady probably needs to clarify that.. 02:54
anyway...
ruoso needs to sleep
JDlugosz It appears that rakudo took it, when parens were added.
Is that BECAUSE of this example?
Why would ^ be different from other operators? No need to auto-hyper it, why not all of them? 02:55
ruoso well.. I think noone considered yet to auto-hyperize normal operators...
but I'll leave that for TimToady 02:56
ruoso night &
02:56 eternaleye_ left 02:57 eternaleye joined 02:59 kate21de joined 03:10 Chillance left, eternaleye left, eternaleye joined 03:19 CMA left 03:20 donaldh left, wknight8111 left, donaldh joined 03:45 cspencer_ joined, cspencer left, cspencer_ left, cspencer_ joined
cspencer_ rakudo: say 1 before 2 03:46
p6eval rakudo ec55f1: OUTPUT«Statement not terminated properly at line 1, near "before 2"␤in Main (src/gen_setting.pm:0)␤»
03:46 cspencer_ is now known as cspencer 03:49 orafu left, orafu joined 03:56 ejs joined 04:02 Kisu left 04:06 agentzh left, agentzh joined 04:40 vx64z left 04:43 lambdabot left 04:45 lambdabot joined 04:53 ejs left 05:10 bacek_ left 05:20 agentzh left 05:21 agentzh joined 05:23 cspencer left 05:33 orafu left 05:41 meteorjay joined 06:09 nbrown left 06:13 orafu joined 06:26 frew left 06:31 c9s joined 06:47 sri_kraih_ left 07:05 iblechbot joined 07:19 FurnaceBoy left 07:20 donaldh left 07:21 donaldh joined 07:29 iblechbot left 07:32 mikehh left 07:42 DemoFreak joined 07:52 kaether left
eternaleye Well that's interesting. In exploring Unicode, I chanced across a symbol which the Arial font has switched with its neighbor 07:53
rakudo: say "\c[CIRCLE WITH UPPER HALF BLACK]" 07:54
p6eval rakudo ec55f1: OUTPUT«◓␤»
eternaleye In Arial, the top it white and the lower half is black.
*is
Patterner I have white letters on black background and the upper half of the circle is white. And I'm sure I don't use Ariel. 07:57
08:25 eMaX left
Eevee I'm pretty sure Unicode glyph names say "black" with the assumption that the font color is black 08:30
eternaleye All my fonts are black font on light background 09:01
Except Konsole, but I use Quassel for IRC
literal "filled" would have worked better than "black" 09:13
09:13 bacek_ joined 09:21 agentzh left
eternaleye ... So I've started building this bikeshed... XD 09:45
09:46 meppl joined 09:47 agentzh joined 10:12 VX joined 10:21 bacek_ left 10:25 pmurias joined 10:32 abra joined 10:34 payload joined, payload left, payload joined 10:35 VX left 10:36 eternaleye left 10:38 eternaleye joined
pugs_svn r26861 | pmurias++ | [re-mildew] Capture.new handles named arguments 10:42
r26861 | pmurias++ | t/signature_named.t passes
10:43 Chillance joined 10:48 abra left 10:51 fridim_ joined 10:52 icwiener joined 11:11 pmurias left 11:14 eternaleye left 11:16 eternaleye joined 11:20 donaldh left, donaldh joined 11:28 masak joined
masak whoz op, #perl6 11:28
the weather is actually too nice in Uppsala to stay indoors, but I just thought I'd pop by and see how you're doing. :) 11:29
rakudo: class A { method postcircumfix:<( )>() { 42 } }; my $a = A.new; say $a() 11:31
p6eval rakudo ec55f1: OUTPUT«invoke() not implemented in class 'A'␤»
masak will the above ever work?
mberends will you return to more constructive pursuits when it does? 11:33
masak :)
no promises.
11:33 eternaleye left
masak the reason I'm asking is that I seem to recall that .() was special-cased in some way. 11:33
jnthn masak: That problem may disappear when pm does various list refactors. 11:34
jnthn also doesn't intend to stay indoors this afternoon either.
masak mberends: oh, and good day, sir. is there anything in particular that you would prefer I focus on, in terms of constructive pursuits?
jnthn: OH HAI
11:35 eternaleye joined
masak jnthn: so, "yes, it will eventually work"? 11:35
jnthn masak: H H
mberends declaring the spaceship operator is also fun, infix:􏿽xAB<=>􏿽xBB
jnthn masak: I think perhaps you may have to implement elems too.
masak jnthn: 噢你好 :)
jnthn masak: However, doing that at the moment doesn't help either.
mberends and a nice day to you's all 11:36
masak jnthn: we should have a list of the things you're expected to implement when making a class do Callable, Associative and Positional...
jnthn masak: Oh, I completely read your example as [ ], not () 11:37
oop
s
You wouldn't need elems for that one.
And I'm not quite sure when we'll make that one work.
It depends on solving a nasty nasty Parrot issue.
masak jnthn: it's ok, I didn't reflect on the insanity of your reply. :P
mberends masak: no, leap year arithmetic was just making me crabby
masak mberends: you're a brave man, sir. 11:38
mberends: have you done leap seconds yet?
mberends aaaargghh!
masak mberends: it'd be fun to create an expert system that can answer the question "which was the longest year?" 11:39
mberends szabgab++ kicked my Padre installation into shape :)
masak yes, I backlogged as much.
mberends Padre support for Perl 6 is still young, needs more testers 11:40
11:42 payload1 joined, payload left
masak mberends: I had a mind to hack some on Druid yesterday, but got distracted by everything and nothing. maybe today I'll get a chance, if the nice weather doesn't completely overpower me. 11:45
11:45 bacek_ joined
masak I have two interesting leads to follow: the SVG thing, and the Web.pm thing. 11:45
they actually interact a bit, too.
mberends masak: I suggest try the Web.pm first for -Ofun 11:46
masak mberends: I already did, a few weeks ago.
but it needs a bit of polish. 11:47
bin/web-druid
(a type of script that we keep seeing more and more often nowadays -- HTTP::Daemon++) 11:49
mberends enjoy! I really want to move along my todo list as well.
jnthn eyes his todo list fearfully
mberends that Daemon does get around, in new forms :) 11:50
jnthn OK, off to the castle, and the river(s) and the sun. bbl
masak mberends: in fact, it might be a good idea to provide the functionality being copy-pasted everywhere in HTTP::Daemon itself, making it work out-of-the-box with certified Web.pm apps.
11:50 mib_4qajcr joined
masak jnthn: enjoy! 11:51
jnthn masak: You too, whatever you choose to do in the sun. :-)
11:51 mib_4qajcr left
masak jnthn: read, probably. thanks. :) 11:51
mberends masak: that's a good idea for what to do with the core code.
with help from Tene++ maybe SMTP will become a similar core. 11:52
masak mberends: I'm having a look at HTTP::Engine from CPAN, and seeing if we can learn something from that.
mberends: but I think a wrap-HTTP::Daemon-around-a-Web.pm-app script would be good for dependency reasons. 11:53
having Web.pm depend on HTTP::Daemon does not exactly square with it being engine-agnostic, as I've recently come to realise. :/ 11:54
that said, we should definitely make it super-easy to hook the latter into the former.
mberends masak: for the wrapping, a CGI style API (not CGI.pm) would link them agnostically, and even resemble Apache and mod_perl interfaces. It mainly uses %*ENV. 11:55
masak mberends: as does Rack. sounds good. 11:56
mberends ok, Rack too. nice.
masak: can do, need a break from Feb-29 and all that. 11:57
masak (Feb 29)--
mberends++ 11:58
mberends masak: on another front, started writing my YAPC::EU talk this week :)
11:59 eternaleye left
masak mberends: hint taken. :P 11:59
masak still very much likes the second photo in howcaniexplainthis.blogspot.com/200...hotos.html
mberends a kind of rain dance? 12:00
masak I have no recollection of the specific situation that caused me to do that.
12:00 eternaleye joined
masak but it appears I'm enjoying myself. 12:01
mberends I'm planning to publish by talk WIP (10% done) soon - will you also? 12:02
*my
masak depends -- what's a WIP?
mberends Work In Progress, sorry
masak oh, good idea. I could keep it in the Web.pm repo.
that'll also spur me to port my Amazing Slide Software (tentatively called 'Hubris') to Perl 6. 12:03
mberends :-) Hubris. I've already invoked Laziness in mine.
my Slide Software is going to have to be a Pod6 emitter 12:05
12:09 masak left, masak joined
mberends masak: rehi. HTTP Engine at first sight appears to be cloneable 12:09
12:10 eternaleye left 12:12 eternaleye joined
masak
.oO( neighbour's wifi... )
 12:15
12:15 masak left 12:21 DemoFreak left 12:22 DemoFreak joined
mberends @tell masak re: HTTP-Engine, see also search.cpan.org/~beppu/Squatting-0....okbook.pod 12:23
lambdabot Consider it noted.
12:28 c9s left, c9s joined 12:40 bacek__ joined 12:41 payload1 left 12:43 eternaleye left 12:44 bacek_ left 12:46 eternaleye joined 13:01 eternaleye left 13:04 eternaleye joined 13:06 payload1 joined 13:10 Whiteknight joined 13:12 bacek__ left 13:14 lichtkind joined 13:15 cognominal left
lichtkind does anybody know the nickname of conrad schneiker? 13:21
13:23 eternaleye left 13:25 abra joined 13:26 eternaleye joined 13:42 eternaleye left 13:44 eternaleye joined 13:46 meppl left 13:54 pmurias joined 14:00 eternaleye left 14:02 jhorwitz joined 14:03 eternaleye joined 14:06 ruoso_ joined
ruoso_ pmurias++ # more tests passing... 14:06
pmurias, the segfault in the other test is being caused by refcounting bugs... 14:07
14:07 ruoso left, ruoso_ is now known as ruoso 14:08 nihiliad left
s1n do trait_auxilary apply to methods as well? 14:10
ruoso yes
method foo is export { }
s1n ruoso: thanks :) 14:11
14:11 payload1 left, eternaleye left, obra_ joined 14:13 nihiliad joined 14:14 eternaleye joined, payload joined 14:24 cognominal joined 14:27 cspencer joined 14:30 eternaleye left
pmurias ruoso: hi 14:31
14:32 eternaleye joined 14:35 ruoso left 14:36 ruoso joined 14:37 CMA joined 14:41 kate21de left 14:42 iblechbot joined 14:45 M_o_C joined
s1n Tene: i tried doing something similar to your LolDispatch, but i seem to be doing something wrong, i'm seeing "No method named 'trait_auxiliary:is' to remove in class 'TestDispatch'." 14:46
14:50 meppl joined 15:01 justatheory joined 15:04 justatheory left 15:05 eternaleye left 15:07 eternaleye joined 15:12 eternaleye left 15:15 eternaleye joined 15:20 donaldh left, donaldh joined 15:30 eternaleye left 15:32 eternaleye joined
Tene s1n: that's a bug in rakudo when defining subs in classes. Both jonathan and I have looked at it. I might look into working around it today, but the proper fix depends on the work in the .HLL_map branch. 15:35
s1n: you need to define it in a 'module', not a 'class' for now. 15:36
s1n: the big problem I ran into when working on this is trying to get the invocant from the caller.
Parrot doesn't actually expose that information in PIR, afaict.
I patched Parrot to expose it, and ran into a segfault. 15:37
15:40 Gothmog_ left 15:41 payload left 15:45 Chillance left, Patterner left, Psyche^ joined, Psyche^ is now known as Patterner 16:14 mikehh joined
TimToady funny thing is that Class isa Module, on some level or other, so if it works in a module, it ought to work in a class 16:26
jnthn TimToady: Happily, we're exploding in some code that is a hack to work around something that (as of a few days ago), we won't need to work around. 16:28
TimToady: Basically it's making the un-good assumption that if something is in a class, it must also be a method. 16:29
I could fix that up too somehow, but I'd rather spend time just ripping out the code in question anyway. :-)
16:33 ruoso left
cspencer should Range eventually expose a .by method to get at the increment? 16:34
16:35 jhorwitz left
Tene oh... release is coming up soon. If I'm going to get this inter-language library import stuff into this release, I'd better do it soon. 16:36
jnthn cspencer: Most likely yes. 16:39
cspencer jnthn: and for the to_exclusive/from_exclusive too, i imagine then?
jnthn: though those names are somewhat cumbersome
jnthn Yeah, .by will do well for a name, but those probably won't. 16:40
I don't do naming though. :-)
Most things I tried to name in Parrot, other people came along with a better name for. ;-)
cspencer jnthn: heh, okay, i'll add in a .by method and leave the others for later :) 16:41
16:42 cspencer left 16:51 Gothmog_ joined 16:54 icwiener left 17:01 eternaleye left 17:04 eternaleye joined
pmurias jnthn: will we support merging ranges? 17:06
17:06 eternaleye left, eternaleye joined
jnthn pmurias: Merging ranges? 17:06
pmurias: Gotta run to the shops quickly...need food...piwo ;-) 17:07
17:08 justatheory joined
pmurias :) 17:08
like having a range from 1..3 and 5..8
17:13 justatheory left
s1n Tene: i changed it to a module (which i thought was essentially just a package as well), but i now get null pmc access in invoke... 17:14
moritz_ re
17:18 ruoso joined
Tene s1n: what are you trying to invoke? Can I see the code? How are you extracting the invocant from the caller? 17:18
s1n Tene: yeah, lemme touch it up and gist it 17:19
Tene I wasn't able to get the invocant from the caller in any reasonable way.
also, can there be a sub and a method of the same name in the same namespace?
I think so, but I haven't verified. 17:20
ruoso as long as you don't use my or our in the method, you can
my method foo {} # declares &foo 17:21
our method foo {} # declares &foo and register in $?PACKAGE
method foo {} # no lexical or package
pugs_svn r26862 | moritz++ | [t/deprecated-syntax.pod] remove some paragraphs that are either out of date or typically not a problem anymore 17:22
17:22 eternaleye left
pugs_svn r26863 | moritz++ | [t] merge init-in-exported-sub.t into spec/S10-packages/basic.t 17:22
s1n bleh, i'm getting malformed routine now
i'll just gist it and see if you can help
17:24 pmurias_ joined
s1n gist.github.com/113062 17:24
oops, hmm, i think i misnamed the module
how did i not notice that until just now
17:25 eternaleye joined
s1n well, i still get malformed routine def at line 21 17:25
17:26 masak joined
moritz_ s1n: that's because the multi trait_auxiliary:<is> isn't visible in the scope of line 21 17:26
masak @messages
lambdabot mberends said 5h 3m 43s ago: re: HTTP-Engine, see also search.cpan.org/~beppu/Squatting-0....okbook.pod
masak mberends: will read. thanks.
@clear
lambdabot Messages cleared.
s1n moritz_: okay, is it feasible to move it into FooDispatch? 17:27
moritz_: because even when i move it into FooDispatch, i still get "Malformed routine definition at line 19, near "foo() is f"" 17:28
moritz_ s1n: I don't know (yet) what the right solution is, sorry
jnthn pmurias: Ja mam piwo! ;-)
pmurias: I guess you could just make a list with the two ranges in and make sure you keep it in lazy contexts... 17:29
s1n moritz_: that's okay, i'm looking to see what i'm doing wrong. Tene's LolDispatch was so interesting, i wanted to play with it :)
moritz_ s1n: I have some backlogging to do, and if you haven't found your problem until I'm finished I'm glad to investigate more... 17:30
s1n: that said, try to pars it with STD.pm, perhaps you just have a syntax error and STD.pm gives you a better error message
17:31 CMA left
s1n moritz_: how do i pass that through STD.pm? 17:31
moritz_ cd src/perl6/ # in pugs
17:31 brrrrr joined
moritz_ ./tryfile $filename 17:31
you need 'make' as step 1.5 ;-)
17:38 brrrrr left
s1n moritz_: i had to do a 'perl tryfile $filename' (because my perl is elsewhere) and it complaining about STD.pm barewords... 17:40
moritz_ s1n: did you do a 'make' first?
s1n no, perl was always elsewhere, i'll have to change that to make it work
17:40 pmurias left
pugs_svn r26864 | moritz++ | [S02] remove a left-over $<?> (now $/.ast) 17:41
moritz_ s1n: 21 sub foo() is foo_command(/^foo) { # you need to close that regex 17:44
s1n moritz_: doh!
bleh, the p5 syntax highlighter in vim usually clues me to that one 17:45
now i'm getting the null pmc access in invoke again
moritz_ s1n: use the p6 syntax hilighter
s1n moritz_: check line 26 :) 17:46
17:46 alester joined
moritz_ ;-) 17:47
17:51 sri_kraih joined
Tene s1n: you're still having problems? 17:53
sorry, stepped out for lunch.
17:53 rewt left
JDlugosz I'm at my desk, working on Perl. 17:55
s1n Tene: yeah, moritz_ fixed the sub def error i was getting, still getting null pmc access 18:02
Tene s1n: update your gist and I'll check it out 18:03
s1n Tene: updated 18:05
18:05 iblechbot left
s1n all i did was "perl6 -e 'use FooDispatch'" 18:06
masak moritz_: oh, you don't like the each() comprehension?
moritz_ masak: not as it is now
masak: right now it works in one syntactic special case, which makes it rather obscure
masak moritz_: I found your comment about it in t/TODO, and then re-read the part about each(), and found it quite quirky and a bit amusing. 18:07
moritz_: but I must confess to never having needed it.
moritz_: fwiw, I think you're onto something in the email. 18:08
moritz_ masak: did you know about it before you read my comment?
masak moritz_: nope. :) but I must have skimmed over that part of the spec at some time.
moritz_ actually when I wrote it wanted to write something like "can we get rid of that bullshit?"
18:09 nihiliad left
moritz_ but I then remembered some earlier Junction tests 18:09
which assumed exactly the semantics that each() has, in this special case
masak moritz_: that's what you wrote in the TODO file, IIRC. :)
moritz_ so I thought maybe there's some merit after all
masak sorry, t/TASKS
yup, "container/each.t: wtf is each? do we still need it?" 18:10
:)
JDlugosz Can someone talk about "Subexpressions circumfixed by parentheses" as described in S03 ?
ruoso ^^^^^ 18:11
TimToady ^^^^^
ruoso explained yesterday how () are now a Capture constructor, no \ needed. 18:12
moritz_ that surprises me a bit
JDlugosz But S03 reads, "Parentheses are parsed on the inside as a semicolon-separated list of statements, which (unlike the statements in a block) returns the results of all the statements concatenated together as a List of Capture."
moritz_ that's my state of knowledge too
ruoso note the "semicolon-separated" 18:13
(1,2,3) returns a capture
(1,2,3;4,5,6) returns two captures
JDlugosz Not a Capture, but a List OF Capture. I was expecting a single Capture with the kind of non-flattening at the semi's that we've seen for subscripts.
masak JDlugosz: what ruoso just said. 18:14
frew|work what's the diff between a capture and a list?
moritz_ any idea what happened to t/spec/S04-statements/do.t?
JDlugosz It doesn't say that a circumscribed subexpression without semis does anything different.
ruoso but I think that part would look better "all the statements concatenated together as a Capture of Captures"
moritz_ rakudo now aborts after 16 tests or so
is that deliberate?
ruoso frew|work, a capture is a context-less container 18:15
JDlugosz So the singular case is different? No extra wrapping that somehow keeps out of the way?
s1n Tene: any idea what's wrong?
ruoso a list defines a container
masak frew|work: Captures participate in binding (of variables and function arguments)
ruoso *a context
pugs_svn r26865 | moritz++ | [t/spec] stop rakudo from prematurely aborting do.t 18:16
ruoso JDlugosz, it certainly depends on how you look at it... but I guess there isn't much difference between 18:17
(1,2,3;4,5,6) and ((1,2,3),(4,5,6))
but I'm not sure about that
JDlugosz OK, that makes sense and is a good way to explain it.
But, without semicolons, you don't get double-bagged, right?
ruoso it would be a shame if you did 18:18
since most of the time we deal with single-dimension captures
JDlugosz It's like the () is a capture constructor, as explained yesterday, and the semicolons also, indpendantly, is a capture constructor.
ruoso yeah... I'd think that as infix:<;> vs circumfix:<( )> 18:19
JDlugosz So in any kind of list, 1,2,3;4,5,6 gives two captures rather than 6 Ints.
Put the two together, it works out as you described.
So... what about the explaination I learned about ; in a list just marking the spots, with a separate non-flattening context being optional? 18:20
Is that gone totally, for subscripts and everything?
And instead, semi's produce nested lists in a fairly ordinary and very understandable way? 18:21
Tene s1n: it works perfectly when I move FooDispatch into a separate file.
ruoso JDlugosz, the flattening only happens later
if you assign to a list 18:22
for instance
Tene s1n: that is, when I put the foo_command'd sub in a different file from FooDispatch
moritz_ so it's really an exporting issue?
Tene s1n: it has to do with the timing of when things are put in the right places during compilation and when the trait_auxiliary stuff is called. 18:23
moritz_ you could try a FooDispatch.import() or FooDispatch.IMPORT() or however it's called
JDlugosz OK, I'll come back to that in a moment. But what I said is correct? It (now) makes a list of Captures?
18:24 pmurias_ is now known as pmurias
JDlugosz As for flattening: I recall that a list where an item is expected in list context will flatten. So the Capture allows that to happen too, just like the literal list. Captures, in general, defer decisions. 18:24
Tene But when you put it in a different file, all of that happens as soon as rakudo sees the 'use' statement.
JDlugosz So, given my Capture $c := (1,2,3); 18:25
Strike that, should be: my Capture @c := (1,2,3); 18:26
then my Capture @d := (10,@c,20); 18:27
@d holds a nested Capture, but 18:28
lambdabot Maybe you meant: devils dice dict dict-help djinn djinn-add djinn-clr djinn-del djinn-env djinn-names djinn-ver docs dummy . ? @ id v
JDlugosz my @A= @d;
will flatten, giving 10, 1,2,3, 20.
Tene s1n: what's your purpose in putting foo() in FooDispatch btw? 18:29
JDlugosz But @d still has a nested structure. How do I view it as such, getting back the non-flattened top list? That was previously described as using the @@ context. 18:30
I'm supposing that the Positional interface to Capture will present the flattened view. 18:31
Binding to variables through a Signature will see the non-flattened view. That's parameter passing. 18:32
18:33 nihiliad joined 18:34 VX joined
s1n Tene: because moritz_ said trait_auxiliary:<is> wasn't visible 18:38
Tene: should i put FooDispatch in one file, and the call to dispatch() in another file?
Tene s1n: that's because you weren't importing the class youd efined there.
s1n: yes 18:39
or, if you want to keep it like that, do something like FooDispatch.import() oslt
i don't remember the details to do that.
s1n why would i have to import FooDispatch in the same file?
moritz_ because subroutines are scoped to the current module 18:40
not to the file
Tene s1n: because symbols are lexically scoped. Defining a class or module isn't the same as asking its symbols to be imported into the scope you deifned it in.
moritz_ it's like in perl 5: { package foo; sub bar { }}; bar() # book 18:41
s/book/boom/
s1n okay, how do i import this properly then?
moritz_ that's a good question 18:42
Tene s1n: I strongly recommend you just put them in different files for now.
i think there's a related bug here, but I'm not sure and don't have the time to track it down right now. 18:43
s1n Tene: i can do that, would i just use FooDispatch then?
Tene yes.
moritz_ rakudo: module A { sub f is export { 3 } }; A.import(:DEFAULT); say f() 18:44
p6eval rakudo ec55f1: OUTPUT«Null PMC access in getprop()␤»
s1n Tene: should i be able to do the call to dispatch from the command-line?
moritz_ rakudo: module A { sub f is export { 3 } }; A::import(:DEFAULT); say f()
p6eval rakudo ec55f1: OUTPUT«Null PMC access in invoke()␤»
s1n -e 'use FooDispatch; dispatch("foo")'
moritz_: is that supposed to work?
Tene s1n: put the foo() definition on the command line, and yes.
s1n Tene: the handler has to be in a different file too?? 18:45
masak I've asked this before, but gotten contradictory answers: if I'm in a script and import modules A and B, and A exports a bunch of subs which override Perl 6 core subs, will these still be overriddent in module B?
moritz_ masak: no.
Tene s1n: put the module in FooDispatch.pm. Then, in a separate file, put: use FooDispatch; sup foo is foo-handler() { ... }; dispatch(); 18:46
s1n: like I said before.
moritz_ masak: B unly sees the overridden symbols if it uses `lift#
*lift
masak moritz_: among the two possible answers, that's the one I like.
JDlugosz masak: no. In Perl 5, the override is lexical. In Perl 6, it should be the same.
masak moritz_: I've actually been bitten by Rakudo implementing the other answer. :/
moritz_ masak: then do your job (and rt it) ;-) 18:47
masak moritz_: yes.
JDlugosz Then again, it depends on *how* it overrides the core subs.
masak moritz_: last time I tried, there was a bug earlier in the chain.
moritz_ JDlugosz: no.
masak moritz_: I'll give it a go again now.
JDlugosz If it wraps them, the change is global. The same symbol is assigned a different meaning.
moritz_ JDlugosz: the setting is immutable once it's loaded
s1n Tene: i'll try that in a bit (errands), is that a bug and should i file? 18:48
moritz_ JDlugosz: so calling .wrap on core function either does its job lecxically, or fails
Tene s1n: yes, there's a bug there.
JDlugosz What "setting"?
Tene I'm not sure exactly what it is.
moritz_ JDlugosz: all the built-ins reside in a scope called "setting"
JDlugosz I don't recall wrap being descibed to work differently for things that reside in CORE.
setting: OK. 18:49
moritz_ JDlugosz: and to all modules and scripts it looks like an outer lexical scope
18:49 skids joined
moritz_ (it's rather newish, might be 3 months old or so) 18:49
18:49 abra_ joined
JDlugosz CORE <+ SETTING < UNIT < (your_block_here) 18:50
er, <=
For standard stuff, SETTING is the same as CORE. startup options -n and -p put stuff in CORE to make a DSL.
So, I can see defining a sub in SETTING to lexically hide the rock-bottom-default from CORE. 18:51
moritz_ or maybe it's the other way round, and CORE is imutable
JDlugosz But that's not the same as calling .wrap.
moritz_ I haven't really grokked it
JDlugosz Perhaps (most) built-ins will complain if you try to wrap them, e.g. the Routine is readonly. 18:52
Error message suggests defining yours in SETTING to hide it, instead.
All the modules see the same SETTING for the program. They have different UNIT scopes. 18:53
That has implications for pre-compiling modules. Basically, the SETTING can affect the meaning of the module at "compile time" if compiles when loaded like P5. 18:54
But the hope is that stuff can be pre-compiled. I can see making the loader treat subs in SETTING as bascially a formal way to override the CORE, but that doesn't help names that are defined of a different fundimental class, and change the meaning of the parsed text. 18:56
18:56 jferrero joined
moritz_ JDlugosz: but as I understand it the intention is that unless a module requests something else, it will always get the "normal" built-ins 18:57
JDlugosz That (fairly new) section in S02 needs work.
moritz_ JDlugosz: so that 'use B' can not mean somethiing else if there was a 'use A' before
did I understand that correctly?
JDlugosz I agree with you, moritz_. The meaning should be fixed unless explicitly using contextual symbols or generics. 18:58
moritz_ good.
JDlugosz So, given that the intent of SETTING is to provide a DSL, not to hot-wire the meanings of modules, a module should behave as if pre-compiled, and that means being independant of the main program. 18:59
18:59 abra left
JDlugosz Compiling a module (for later use) has its own SETTING layer, which is unrelated to that of the main program. 18:59
That's my thought. I'll make notes to work over the S02 later. Buzz me if anyone has more input on the matter. 19:00
moritz_ none but "I agree" ;-)
JDlugosz I think my working style will be to present a whitepaper or tutorial first, that's less formal and explains the rationale. Then later update the Synopses if they are well-received, and the whitepaper can become a "rationale" unofficially. 19:02
19:05 Whiteknight left 19:07 iblechbot joined
moritz_ masak: did you submit your grant proposal? 19:09
masak moritz_: aye, on Friday. rdice already replied, saying "how's it going with the Web.pm grant?"
a very reasonable question.
I wrote a reply a few hours ago.
(I expect to finish my part of Web.pm by early June) 19:10
moritz_ ok
19:11 payload joined, abra_ left 19:20 donaldh left, donaldh joined
masak oh, and another thing: errors are written to $*OUT in Perl 6? 19:22
why?
erm, in Rakudo.
Tene that seems like a mistake.
masak it does indeed.
it's hard to demonstrate with p6eval. 19:23
rakudo: run('./perl6 "die q[OH NOES]" > /dev/null') 19:24
p6eval rakudo ec55f1: OUTPUT«Unable to open filehandle from path 'die q[OH NOES]'␤current instr.: 'perl6;PCT;HLLCompiler;evalfiles' pc 75371 ((unknown file):-1)␤»
masak rakudo: run('./perl6 -e "die q[OH NOES]" > /dev/null')
p6eval rakudo ec55f1: ( no output )
masak see?
moritz_ rakudo: run('./perl6 -e "die q[OH NOES]" 2>/dev/null')
p6eval rakudo ec55f1: OUTPUT«OH NOES␤in Main (<unknown>:1)␤»
masak submits rakudobug
mberends funny, warn() and die() write to 2>/tmp/whatever here 19:31
p6eval might have a 2>&1 kind of trick 19:32
masak so, platform-dependence?
mberends yes
19:33 kate21de joined
mberends calling environment 19:33
19:33 meppl left
jnthn yes, should be going to stdin 19:35
moritz_ *in*?
;-)
jnthn o jebat...
stderr
I fix this week.
Along with the sometimes-missing-backtrace issue.
masak yes, plz fix.
moritz_ jnthn: do you know how I can call import manually? 19:36
masak this is the closest to an outrageous bug that I've found for quite some time.
moritz_ rakudo: method A { sub f is export { 3 } }; A::import(:DEFAULT); say f()
p6eval rakudo ec55f1: OUTPUT«Null PMC access in invoke()␤»
moritz_ jnthn: is that how it's supposed to work? 19:37
Tene rakudo: module A { sub f is export { 3 } }; A::import(); say f();
I think you mean.
p6eval rakudo ec55f1: OUTPUT«Null PMC access in invoke()␤»
moritz_ Tene: ah, yes
masak that's in RT, though.
moritz_ result is the same
masak: ah, I didn't know that 19:38
Tene yes, but s/method/module/ is important :)
masak "calling sub in module" is, yes.
moritz_ rakudo: module A { sub f is export { 3 } }; A::import(:DEFAULT); say "alive";
p6eval rakudo ec55f1: OUTPUT«Null PMC access in invoke()␤»
Tene rakudo: module A { sub f is export { 3 } }; say A::f();
p6eval rakudo ec55f1: OUTPUT«3␤» 19:39
moritz_ isn't sure if masak meant the same thing
masak rt.perl.org/rt3/Ticket/Display.html?id=64876
jnthn masak: Meh. Gotta let you have something to complain about now and then. :-P
moritz_ ;-) 19:40
jnthn moritz_: I think it's IMPORT too, but NYI.
masak jnthn: well, it's been a while since I had something really good to complaing about. :-P
mberends masak: pugs/misc/evalbot/evalbot.pl:96: cmd_line => $input . '| ./perl6 %program >> %out 2>&1',
moritz_ jnthn: ok, thank you
masak: it's not quite the same thing, not quite the same error message
jnthn moritz_: Importing is currently one of those things we cheat on a lot.
19:40 Fuad joined
masak mberends: yes, but note that the run(...) call doesn't follow those rules. 19:40
Fuad Hello folks 19:41
mberends hi Fuad
masak Fuad: hello!
Fuad :)
jnthn moritz_: Mostly because I just needed something good enough to let us import stuff from the setting, and wanted to handle tags at some level too.
masak Fuad: did you read the source I threw at you last time?
Fuad masak: yes i was working on it,dude 19:42
moritz_ jnthn: fine by me... I'm just thinking about the traits stuff...
masak Fuad: let me know how that goes.
moritz_ jnthn: should I move the roles defining the traits to an external module?
jnthn moritz_: Aye, traits are kinda blocking on input.
(From TimToady++)
19:43 keepguessing joined
jnthn moritz_: Are you looking at testing traits some more? 19:43
moritz_: If so, I'd advise you put it off a bit - I know TimToady is mulling them over and I've no real way of guessing how radical the changes are going to be.
19:44 aindilis joined
moritz_ jnthn: I'm just looking at testing what's implemented right now 19:44
jnthn moritz_: OK, feel free, but be aware that (a) the spec is one of the bits currently very liable to change and (b) I don't plan any more implementation until there's some progress on the spec. 19:46
moritz_ jnthn: ok
jnthn Just don't want to encourage you to spend a bunch of time on something that I know could change (possibly a lot) shortly. 19:47
19:47 Fuad left
moritz_ jnthn: thanks 19:53
getting the current tests to pass on rakudo seems non-trivial
so I abort for now 19:54
jnthn moritz_: I didn't get far into traits before I blocked on spec. :-)
19:54 ejs joined 19:55 ruoso left, justatheory joined
mberends masak: pushed minor change to proto 20:05
masak mberends: pulling.
dalek kudo: 2949868 | jnthn++ | perl6.pir:
Make sure backtraces are printed to STDERR; printing them to STDOUT outrages masak++^W^Wis very wrong.
 20:06
masak jnthn: I'm suddenly much less outraged. :) 20:07
mberends: no twigil because I'm a very forgetful person. :/ 20:08
mberends it works all the same :) 20:09
masak I'll add a twigil.
(and remove the TODO comment that you implemented, mberends++)
Tene pmichaud: ping? going ot be around today?
masak mberends: oh, my 'if !' instead of 'unless ' is just a personal preference. I don't mind you changing it to the latter, but I'll probably keep writing the former. 20:10
mberends 50/50, ok
masak mberends: partly because of PBP, partly because I find it easier to reason about.
moritz_ likes 'if !...' better too 20:11
masak I don't mind statement-modifying 'unless' at all, though. strange. :)
moritz_ ;-)
Tene I prefer 'unless'... make it more obvious I'm looking for a negative. I tend to overlook !s.
moritz_ well, reading an 'unless ... { ... } else { ... }' is rather confusing (but forbidden in p6, iirc) 20:12
Tene rakudo: unless 1 { ... } else { say "hi" }
p6eval rakudo ec55f1: OUTPUT«unless does not take "else" in Perl 6; please rewrite using "if" at line 1, near "else { say"␤in Main (src/gen_setting.pm:0)␤»
Tene :(
;_;
oh well, I'm over it now.
masak mberends: make_pir_modules is a nice addition, but I still think we should have a real Makefile :)
...eventually. 20:13
mberends masak: the reason for the refactor was to try to get "Building proto" to happen at first execution, but that would assume that the default RAKUDO_DIR was already correct
masak mberends: also, the final Pod doc looks incomplete.
mberends: "Some possible changes, subject"
mberends it looks terribly out of date
after your Ecosystem separation, the name Installer no longer describes what it does too well. 20:15
masak it doesn't?
I thought the name became more apt after the disfactor. :)
masak skims Installer.pm
mberends: though I did briefly ponder naming them Proto::Installer and Proto::Ecosystem, respectively. 20:16
mberends update, test, and showdeps are not actually installing anything 20:17
and from my soapbox, I think 'subcommand-dispatch' is overly pompous.
masak no, but couldn't 'installer' be a sort of catch-all term? 20:18
mberends: granted, subcommand-dispatch is pompous. :)
mberends I can only offer criticism right now, not constructive suggestions ;)
masak 哈哈
it would be fun if someone wanted to write a review of proto. 20:19
lurkers: ^^ 20:20
mberends masak: Installer method new() looks very pretty :-) 20:21
20:22 ejs1 joined
masak mberends: you're referring to the assignment inside a hash value? :P 20:22
mberends yes, the $c
masak hm, variable declaration, even. 20:23
mberends: let's just say I'm glad Perl is as liberal as it is. :)
mberends: I pushed a little fix. 20:24
mberends :) Padre detected the pull and offered to reload :) 20:26
masak I just want to counter Tene's above sobbing (about unless/else being forbidden) by expressing my total contentment about the current state of affairs. :)
Padre++
Tene :P 20:27
masak rakudo: class A does Associative { method postcircumfix:<{ }>(*@ix) { return @ix } }; .say for A.new<foo bar> 20:29
p6eval rakudo 294986: OUTPUT«foo␤bar␤»
masak that's just so cool.
moritz_ masak: care to turn that into a small test case? 20:30
masak moritz_: well, since you ask so nicely... :)
mberends: for the record, I'll scrap contains-project and get-info-on after the next Rakudo release.
mberends: ...replacing it with the above kind of thing. 20:31
20:32 bacek joined
mberends doesn't get it 20:32
masak mberends: essentially making Ecosystem do Associative. 20:33
20:33 ejs left
moritz_ gah, S06-operator-overloading/method.t seems over-engineered 20:33
and wrong. 20:34
or, hm, maybe not 20:35
rakudo: class A { method b { say "A::b" } }; my $x = A; $x.new().b
p6eval rakudo 294986: OUTPUT«A::b␤»
mberends masak: you're just adding sugar with Associative, right? 20:37
masak mberends: no, I'm also removing two methods.
"There should be only one obvious way to do it." :P
moritz_ welcome to python. 20:38
mberends yes
masak moritz_: aye. I'm just being an iconoclast.
moritz_ rakudo: class A { method prefix:<~> { "foo" } }; my $x = A.new(); say "$x"; 20:39
masak moritz_: I found t/spec/S13-overloading/operators.t -- got a better suggestion for a suitable file to put the test in?
p6eval rakudo 294986: OUTPUT«A()<0xb62517e0>␤»
moritz_ masak: I'm currently reviewing t/spec/S06-operator-overloading/method.t if it might be more suitable 20:40
masak it might.
moritz_ hm
but method.t seems to require quite some work
I'd go with the S13 one for now
masak ok.
moritz_ (and add it to t/spectest.data)
masak (and fudge as needed) 20:41
moritz_ it currently passes all two tests ;-)
masak :)
jnthn masak: Happy I decreased your outragedness.
jnthn is finding LiveMocha a HUGE distraction.
masak jnthn: consider yourself today's outragedness decreaser.
moritz_: should it really say 'ok eval', though? I thought we did things like lives_ok nowadays? 20:42
oh well.
masak stops procrastinating actually writing the test
moritz_ eval_lives_ok
(thouge we could change that to eval-lives-ok sometimes 20:43
masak <grammar-nazi>(no, 'sometimes' is used for recurring events.)</grammar-nazi> 20:44
moritz_ s/sometimes/eventually/
better? ;-)
masak I'm not _un_happy :)
moritz_ bah, method.t is a mess 20:45
it actually tests a rather obscure corner case which isn't specced probably 20:46
jnthn Eww.
moritz_: Which one?
moritz_ jnthn: prefix:<~> as methods and multi subs 20:47
jnthn has managed to drag himself away from LiveMocha
moritz_: In S12-methods?
moritz_ jnthn: no, t/spec/S06-operator-overloading/method.t
jnthn moritz_: ah, ok
taking a peek
moritz_ it uses interpolation into double quoted strings to look for a prefix:<~> 20:48
jnthn moritz_: It looks very dubious.
pugs_svn r26866 | masak++ | [S13-overloading/operators.t] added test about postcircumfix:<{ }> 20:49
jnthn multi sub prefix:<~> (Bar $self) # well done, you just declared yourself an arity-2 prefix operator.
moritz_ rakudo: class A { method prefix:<`> { say "foo" } }; `A.new()
p6eval rakudo 294986: OUTPUT«Could not find non-existent sub prefix:`␤»
jnthn moritz_: It'd need exporting, I think.
masak bug?
moritz_ jnthn: why? it's not a method...
masak well, yes it is.
jnthn moritz_: oh, duh
moritz_: 20:50
it is a method
multi method prefix:<~> ($self) { return $.bar }
moritz_ oh, that one
jnthn If there was a : after the $self, it'd be dine.
*fine
moritz_ jnthn: feel free to add it
jnthn moritz_: Well, it's deeper
multi method infix:<+> ($a, $b) { return "$a $b" }
That'd need to be $a: $b
then it looks like it's missing some exporing too IIUC. 20:51
masak what happens if an infix sub or method is declared with too many parameters?
20:51 brrrrr joined
moritz_ masak: it will participate in ordinary dispatch, I think 20:51
masak: and if it has assoc<list>, it might even get called 20:52
masak ah.
jnthn rakudo: sub infix:<epicfail>($a) { }; 1 epicfail 2
p6eval rakudo 294986: OUTPUT«too many arguments passed (2) - 1 params expected␤»
dalek kudo: 1203649 | masak++ | t/spectest.data:
[spectest.data] added S13-overloading/operators.t
jnthn masak: That. :-)
masak dalek is much slower than pugs_svn...
jnthn: makes a lot of sense. :)
jnthn
.oO( must find good use for epicfail operator )
 20:53
moritz_ so only postcircumfix operators can be non-exported subs?
jnthn moritz_: Well, I guess you can always call
$foo.infix:<+>($b)
moritz_ well.
yes
jnthn Oh, wait, do we still have multis being automatically exported though? 20:54
moritz_ dunno
I hope not
jnthn I forget. I remember reading the spec not long back on that and doing what the spec said, but I forget what the spec actually said by now. ;-)
moritz_ because that would mean automatically importing new syntax
which would come close to epicfail ;-)
20:55 M_o_C left
masak ponders going home for the evening 20:55
20:56 iblechbot left
Tene jnthn: interested in reviewing the start of my sketch for inter-language library loading? 20:56
I'm interested in getting additional eyes on this. 20:57
moritz_ jnthn: so when I define a new postcircumfix:«` `», do I have to export it to properly parse? 20:58
Tene moritz_: not in current rakudo, iirc, but that's the spec, again iirc 20:59
jnthn moritz_: Yeah, I expect not...
moritz_: That's a very good question...I think that in Rakudo as we have it today we just say the token is kosher from the point when we parse it onwards. 21:00
Tene: I'm a little tired, but I'll happily look.
moritz_ rakudo: class A { method postcircumfix:«` `»($a) { say "argh" } }; A.new().`3` 21:01
p6eval rakudo 120364: OUTPUT«Statement not terminated properly at line 1, near ".`3`"␤in Main (src/gen_setting.pm:0)␤»
moritz_ rakudo: class A { method postcircumfix:«` `»($a) { say "argh" } }; A.new()`3`
p6eval rakudo 120364: OUTPUT«Statement not terminated properly at line 1, near "`3`"␤in Main (src/gen_setting.pm:0)␤»
jnthn moritz_: Ah, but declaring new postcircumfixes I think will not work.
moritz_ ok
jnthn As in, add them to the parser.
I was quite surprised when Tene++ got circumfixes to work...
21:04 brrrrr left 21:07 meppl joined
patmat seas meppl 21:12
skids pfah, so much for moore's law -- new laptop rakudo at best 2x as fast :-) 21:15
jnthn skids: How old was the previous laptop though? ;-)
Tene jnthn: you see link in #parrot? 21:16
skids several years, on the high end of several
jnthn Tene: Oh, no... 21:17
Tene: looking...
meppl seas patmat
moritz_ skids: well, having two cores can speed up 'make spectest' by another factor of 2
Tene nopaste.snit.ch/16580 21:18
jnthn Tene: re # other attributes?
For Perl 6 I think the set of attributes may be extensible.
21:18 fridim_ left
jnthn There's :auth for example. 21:18
Tene jnthn: for example, Perl 6 is specced as defining a library based on name, author, version, authority, etc. 21:19
jnthn I think author and authority may be conflated, but yes.
Tene jnthn: but, ideally, only name is required. all others are optional and may be ignored by the language you're requesting a library from.
jnthn Tene: I wonder though if we should just say "and you can pass a bunch of others and it's up to the library loader of that HLL to use them"
And if you give it something it can't handle sanely, I guess it can choose to explode in the appropriate way. 21:20
Tene jnthn: I'd prefer if the library loader just ignored them instead of exploding.
21:20 Whiteknight joined
jnthn Tene: Sure, if it's possible for it to do so, that'd be far nicer. 21:21
Tene: Is the list of strings meant to boil down to namespace parts? 21:22
e.g. for use Foo:Bar we'd pass ['Foo','Bar']
Tene Yes.
jnthn ok
Tene python has foo.bar.baz, perl has Foo::Bar::Baz, php has Foo\Bar\Baz, etc.
jnthn DEFAULT: 21:23
# a map of names to symbols
php srsly uses \ for ns sep? omfg.
Tene yes, it does.
21:23 ejs1 left
jnthn For this, I guess maybe we should define what "a map" means. 21:23
I'd imagine ideally for Rakudo we'd just hand back the namespace
Tene hash. string-keyed.
right.
anything that responds to a hash interface 21:24
skids trauma seizure every time he sees the word PHP
jnthn and since it does a hash interface and you can iterate over it, it's good enough.
Is being able to get an iterator part of the hash interface?
If not, we should probably lay down that the thing you had back had really better be iterable.
Tene nodnod
jnthn One other thing that comes to mind. 21:25
Where is the responsibility for not re-loading something already loaded meant to go?
Tene that responsibility is up to the language who is asked to load a library
jnthn OK, I can go with that. But something to make clear. 21:26
Tene it would be entirely correct, if a bit unusual, for a language to make an HTTP request for the latest version of the module every time it was asked for.
for example.
it can do anything it wants, as long as it obeys the interface.
jnthn Oh, for sure, but just to make clear to people implementing the interface that it needs to handle the "you tried to load this again" case.
Tene nodnod 21:27
I mean, I guess we could make HLLCompiler provide a cache...
jnthn I did ponder that but...
Tene the issue is whether any language ever wants to *avoid* caching.
jnthn Well, it also means HLLCompiler needs to have some clue about how to determine module identity too.
Tene nodnod 21:28
case-sensitive, frex
or version
jnthn nod
I think putting a layer of cache in HLLCompiler is probably being too clever and will just lead to hurt.
Tene yes, agreed 21:29
jnthn version: 'v1.0.1' # optional. a string is probably good?
I think Perl 6 it's fine to say things like v1.*
Tene the issue is how different languages represent versioning.
jnthn Do you see that just being something we stringify and the end receiving it should know what to do with it?
Tene Right.
jnthn OK. If it appears in the soruce code, it has gotta be able to appear as a string, so a string is probably good, I agree. 21:30
Tene maybe in one language it's an integer, in one language it's a float, or a string, etc. is 1.2 greater or less than 1.10 ?
jnthn Ugly.
Tene put it in a string, let someone else take care of it. 21:31
jnthn I think "pass the string and let the language deal with it" may be the way.
And if you throw in a string that in that language's version handling is invalid, then it'll just whine.
Tene yes
jnthn I guess we want to make languages all play together rather than try to make all languages the same. :-)
author: "adent" 21:32
In Perl 6 I think that's just auth
But I think once again
Tene it was just an example.
jnthn We just say "and you can hand back whatever other details you want"
Tene "you can put more details in here if the language wants them"
yes
jnthn filename: "/path/to/filename.ext"
version: "v1.0.1"
Did you see those as being optional or required? 21:33
Tene not required, but examples of what a language might provide.
jnthn Ok, then fine.
Again, good to make claer in the spec, but fine.
btw, you talk about get-library but then describe fetch-library. 21:34
Tene in the request, the only required key is 'name'. In the response, the only required key is 'symbols', whose only required keys are 'ALL' and 'DEFAULT'.
jnthn Right, that sounds like a sane minimum.
Tene fixed :)
(I haven't seen any other libraries that offer that functionality, but they might in the future, after seeing the Perl 6 example. :) )
also to give a way for other languages to potentially use Perl 6 libraries better. 21:35
21:35 leroe joined, leroe left
jnthn *nod* 21:35
OK, I think that's all my comments. :-)
Tene Thanks for mentioning clarifications. The degree of agreement is very promising. :) 21:36
I'll start working on it today.
Is it too soon before the release, do you think?
jnthn I suspect that since it adds functionality rather than modifies existing, at least at a Parrot level, it's probably fine. 21:37
Tene OK
21:37 fridim_ joined
masak here's a blog post I just wrote: use.perl.org/~masak/journal/38988 21:37
jnthn That said, it may be good to get slightly wider consensus since ocne it's in a release people can start using it and it's harder to change.
Tene Any ideas of who else I should consult with? 21:38
jnthn Tene: I'd run it through pmichaud.
Tene Yes, I wanted to, but he's not around today. :(
i'll keep it in a branch for now.
jnthn Yeah, well, he's gotta rest at some point. ;-)
OK, sounds sane.
I expect pm will be about tomorrow. 21:39
masak: How are you feets? 21:40
masak jnthn: they ache slightly.
not too bad, considering.
I have a nice large blister on the right one, but I got that from jogging yesterday... which, I think, is what actually prompted me to do the whole barefoot thing. 21:41
rakudo: say +'I have a blister on my right foot'.words # trying to stay on topic :)
p6eval rakudo 120364: OUTPUT«8␤»
jnthn "Our humor is quirky and intellectual, full of a mix of quantum physics, lolcats"...thrown in with the occasional "how iz compiler formed" :-) 21:42
masak rakudo: say +'␤␤␤␤␤␤'.words # trying to stay on topic :)
p6eval rakudo 120364: OUTPUT«0␤»
masak jnthn: I like how #perl6 visits both the highs and the lows in humour. :) 21:43
rakudo: say +''.words
jnthn masak++ # nice post
p6eval rakudo 120364: OUTPUT«0␤»
masak jnthn: dz. :)
going to bed now. my work here is done.
jnthn night 21:44
masak good night.
21:44 masak left
eternaleye rakudo: say (~pi).words 21:49
p6eval rakudo 120364: OUTPUT«3.14159265358979␤»
eternaleye 0.o
moritz_ . 21:50
21:53 leroe joined
leroe hi 21:53
is it just me or google is heavily backing up python than perl?
pugs_svn r26867 | moritz++ | [perl6-projects.org] introductory paragraph 21:54
moritz_ well, the use python for a lot of their web pages
leroe yeah but why google of all companies supports py to perl? 21:55
moritz_ s/the/they/
leroe i mean they're pretty smart enough to know where python stands
moritz_ they seem to think it's not too bad
leroe but in your opinion what are they missing, code wise
i know they got py's creator
so mayve thats why? 21:56
our lecturer advised us too
ive been gathering books on perl until today
:P
he suggested i go learn python
moritz_ honestly, I have no idea why the picked python
but they are free to do whatever they want
leroe is there any advantage using py pver perl 21:57
in any area
moritz_ sure; for example if you want to get hired by google
leroe no i mean technically
syntax, code
concept
moritz_ well, some people like indention for semantics
and some people prefer one way to do it over many ways to do it 21:58
it's a bit like with natural languages
what are your advantages of learning French over German, or the other way round?
it all depends on whom you want to talk to
leroe no but perl seems to be over the top on a lotof things
im sure techn ically speaking its way past python 21:59
that is where i want to know, where exactly
skids one of the python fans I know thinks the language's strength is in its docs.
moritz_ are you talking about Perl 5 or Perl 6?
leroe perl6
perl in general
moritz_ well, the difference between Perl 6 and Perl 5 is quite large 22:00
there is no "perl in general"
leroe well take perl6 to the new python
moritz_ well, then Perl 6 has grammars, for example
with cleaned-up regex syntax, match trees, inheritance of subrules etc.
very good Unicode support (grapheme-level support) 22:01
versioned modules
jnthn multiple dispatch
leroe and what is python lacking in those areas
moritz_ I don't think python has any of the fancy regex stuff
22:02 VX left
moritz_ or meta operators, for that matter 22:02
leroe ah
moritz_ mutable grammar
dev.perl.org/perl6/faq.html has a nice (albeit a bit outdated) list of cool Perl 6 features
leroe ok cool
is it faster than py 22:04
check this www.python.org/doc/humor/#python-vs...ng-to-yoda 22:05
moritz_ Perl 6 is a language specification, not a compiler
so it can't be faster or slower
maybe Perl 5 is faster
leroe ah 22:06
theres much debate lying around py vs perl, didnt realise until today
s1n Tene: you're right, if i move foo() and the call to dispatch out to a different file, it seems to properly work 22:07
Tene: i'm still not sure i understand why that is though
22:07 ruoso joined
leroe moritz_ does making a language compiled make it faster 22:08
like objc
moritz_ leroe: sometimes. 22:09
Tene s1n: it's a a bug in rakudo
moritz_ leroe: for example, Java is compiled to bytecode, but some java VMs have such fast JIT compilers that many programs run faster in Java than in C
Tene it has to do with the timing
moritz_ leroe: ... usually at the expense of eating more memory
s1n Tene: is there one filed about it? 22:10
leroe moritz_: couldnt agree with you more
Tene no idea.
leroe moritz_ what language do you use when programming OO
moritz_ leroe: Perl (and C++ for heavy duty numerics)
s1n perl, duh! 22:11
leroe moritz_: although I don't see how that can be possible =p
logically that is
the comment about java
moritz_ why not? the VM has much more run time information than a compiler can ever have
it knows exactly where the hotspots are
and can optimize the heck out of them
whereas if you try to optimize the heck out of every single piece of code in your program, you loose cache friendliness 22:12
leroe thinking 22:13
you have a point
moritz_ anyway, in 99.5% of all apps that I write speed is not an issue 22:14
leroe i don;t doubt that:P 22:15
s1n moritz_: about 99.5% of the apps i write for my degree always have speed as a consideration (and usually ignored in favor of development time and a very long runtime) :) 22:16
moritz_ s1n: well, the program that I write for my degree makes up for the 0.5% ;-9 22:18
s1n: and it uses SSE friendly matrix products, interfaces Fortran libraries etc, all that nasty stuff just to make it run fast enough :)
thankfully most of that is done by a linear algebra library under the hood 22:19
22:19 lichtkind_ joined
s1n moritz_: what's your degree/focus? 22:20
leroe moritz_: c++ vs java seems a big debate on the web
but yours makes more sense
moritz_ s1n: German "Diplomphysik" 22:21
physics.
s1n moritz_: heh okay, i was just about to ask for the american version :/
graduate or under? 22:22
moritz_ well, the degree is going to be superseeded by the Master of Science
but IMHO it's a bit more than a Master
leroe sweet
germans
big brains
:P
moritz_ (because I did a Master in Scotland, and it was not too tough for me9
leroe the most common name in germany
s1n interesting
leroe in german
what is it?
moritz_ s/9/)/
s1n my degree can't really be helped by sse :) 22:23
master/phd in cs, intelligent system / statistical nlp focus
i just have to wait, sometimes for a week :/
moritz_ eek 22:24
s1n churning out a solution quickly with perl means i can spend more time waiting :) 22:25
22:35 orafu left, orafu joined 22:36 lichtkind left 22:42 skids left 22:44 skids joined 22:56 orafu left 22:57 orafu joined, PacoLinux left 23:05 pmurias left
JDlugosz howdy 23:06
23:13 meppl left
JDlugosz Reading S03, what happened to pair methods? 23:13
leroe doesnt randall come to perl6? 23:15
just wondering..
23:17 orafu left 23:19 orafu joined
ruoso masak++ # beautifull analogy 23:19
JDlugosz hello again, ruoso.
ruoso what's up
23:20 donaldh left, donaldh joined, kate21de left, jferrero left
JDlugosz We were discussing () and ; and had gotten to what is the current understanding of multidimensional array subscripts, compared to how they had been described originally? 23:20
23:25 DemoFreak left
ruoso ok... I think we need TimToady clarification on this... but my guess is that (1,2,3;4,5,6) is the same as ((1,2,3),(4,5,6)) 23:26
23:27 payload left
JDlugosz Anything new concerning their use with subscripts? Used to be a flat thing that just remembered the mark points, and was somehow the same as a list of streams too. Got pretty thick. The above looks like a fundimental enough change that this stuff needs to change too. Hopefully for the better? 23:29
23:32 DemoFreak joined, frew joined 23:33 icwiener joined
ruoso JDlugosz, I think that doesn't change anything in the subscripts 23:34
JDlugosz it certainly changes the details. You think a high-enough level explaination is still the same? 23:35
ruoso well... the major change is that a unflattened list is composed of captures... 23:36
but as capture implements the list api
that isn't much visible
and also (depending on how old is your reading of the spec) 23:37
JDlugosz the Positional API for a Capture will see the flattened list, right? You have to use @@ to see it un-flattened.
ruoso oh right... you have a very old reading of the spec... 23:38
;)
there was an earlier change
JDlugosz age of spec: I'm comparing the current with March 2008 or so.
What earlier change?
ruoso that simplified that... a list is either flattened or unflattened
23:38 orafu left
ruoso and the subscript will respect that 23:38
@a and @@a are now two different variables 23:39
lambdabot Maybe you meant: activity activity-full admin all-dicts arr ask . ? @ v
ruoso and @@a is probably going to be renamed to @%a
with the short form as ¢a
23:39 orafu joined
ruoso which is the capture sigil 23:39
JDlugosz S03 still describes @@ as a contextualizer. Ah, but I see @@ is mentioned on sigiled variables. 23:40
ruoso yes... the change from @@a to @%a was not yet materialized
JDlugosz @% ? Are you joking?
lambdabot Maybe you meant: . ? @ v
ruoso no... actually I'm not 23:41
because @@a was a "slice"
but "slice" is too list specific
but a capture might contain named values as well
JDlugosz So if they are really different containers/contexts now, the Capture supports your choice of Positional and Slice as well as Associative. Much simpler.
Why call it @% ? Sounds like hash-related. 23:42
23:42 bacek left
ruoso hash or list, depend on how you see 23:42
JDlugosz How does a non-flattened list look like a hash? 23:43
ruoso because a non-flattened list is actually non-flattened capture
and capture might look like a hash 23:44
JDlugosz Now that you mention it, I see wording in S03 to the effect that @ are @@ are being separated.
ruoso yes... this is the earlier change I just mentioned
JDlugosz So is @% really going to be the context of a Capture? Or the subset of Capture semantics that just provide both positional and named items ?
ruoso there's no such thing as "context of a capture" 23:45
because capture means precisely "no context"
so @%foo or ¢foo actually mean "do not enforce any context when dealing with this variable" 23:46
JDlugosz So the ¢ role/sigil/context just does Positional and does Associative, and the impelemtation of that interface on Capture returns non-flattened data. 23:47
ruoso exactly
JDlugosz exactly? No, your last line said otherwise. that is, ¢foo has a deeper meaning, is Capture context, what you just said was wrong. 23:48
¢foo[2] has to mean _something_. It can't really be context free.
ruoso ¢foo[2] calls postcircumfix:<[ ]> on ¢foo without enforcing any context *on ¢foo* 23:49
my ¢foo = bar(); 23:50
JDlugosz OK, so in comparison, @foo[2] would do what when calling postcircumfix:<[ ]> on @foo ?
ruoso the context is not enforced when you use the variable
it is enforced when you assign to it
my @foo = bar();
vx
vs
my ¢foo = bar(); 23:51
23:51 icwiener_ joined
ruoso my @foo := bar() 23:51
will still hold unflattened
so... 23:52
sub foo { return (1,2,3),(4,5,6) }; 23:53
JDlugosz I would think the ¢foo = bar(); the return capture from the call by STOREing it in the container bound to ¢foo, which is OK because Capture does the role associated with ¢, whatever that will end up being called.
ruoso my @a = foo(); say @a[3]; # 4
JDlugosz Likewise, @foo = bar(); as you explained before, doesn't convert or unpack anything either. The Capture does Positional.
ruoso my ¢a = foo(); say @a[3]; # fails, since the first dimension only has two elements
JDlugosz Er, I'm mixing up Item containers and other variables. Let me try again: 23:54
ruoso my @a := foo(); say @a[3]; # fails, since the first dimension only has two elements
skids wait, on that last one, wouldn't that make it difficult to bind to a list of lvalues? 23:55
JDlugosz The case I understand: @x = bar(); will take the Capture returned by bar, and do list assignment between the Array (or whatever it was declared to be) on the left with the thing that does Positional on the right.
skids (that you want flattened?)
ruoso JDlugosz, thus generating a flattened list
JDlugosz That is, it will copy the elements between containers, or the lazy version therof.
23:55 payload joined
JDlugosz You said "will still hold unflattened" but the example @a[3]; implies that it is flattened. 23:57
ruoso JDlugosz, see the comment after it...
skids := vs =
23:58 icwiener_ left
ruoso skids, re: your earlier question: when you assign @a = @b, @a[0 23:58
gah
skids tries to suss how one would bind a slice of array elements to a list of lvalues
ruoso skids, re: your earlier question: when you assign @a = @b, @a[0] === @b[0] will be true
JDlugosz Sorry, still confused. are you saying the flattening takes place during the list assignment, not in the Positional interface itself? 23:59
ruoso JDlugosz, YES!
JDlugosz If so, how would list assignment know it's flattenable, and how does it drive it differently?
ruoso list assignment *always* flatten
skids ruoso: right, but what if your lvalues are not in Array but List?
JDlugosz Oh, because you need a new form of list assignment that takes a Capture on the right, not just a Positional.
23:59 orafu left

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!