»ö« | perl6.org/ | nopaste: paste.lisp.org/new/perl6 | evalbot usage: 'perl6: say 3;' or rakudo: / pugs: / std: , or /msg p6eval perl6: ... | irclog: irc.pugscode.org/ | UTF-8 is our friend!
Set by diakopter on 25 January 2010.
00:00 mj41_ joined 00:15 dduncan joined 00:17 mj41 left 00:19 baest_ joined 00:20 baest left 00:23 dduncan left 00:24 spinclad left, renormalist left, Tene left, teneighty left, nbrown left, gabiruh left, avar left, frew left, akl left, p6eval left, hatseflats left, pnu left, gabiruh_ joined, avarab joined, hatsefla1s joined, Tene joined, avarab is now known as avar 00:28 nbrown joined 00:29 meppel left 00:32 frew joined 00:39 mssm left 00:41 lumi left 00:50 patspam joined, am0c joined, Mantis joined 00:52 xinming_ joined 00:56 sundar left 01:06 pmurias left, niros left 01:10 xinming left 01:11 lestrrat is now known as lest_away 01:13 xinming joined 01:14 Chillance left 01:15 rgrau left 01:20 niros joined 01:23 lest_away is now known as lestrrat 01:31 xinming_ left 01:33 LaVolta joined 01:41 patspam left 01:44 ShaneC1 left 01:46 kcwu_ left 01:48 partisan joined 01:50 araujo left, cdarroch left 01:51 [particle] joined 01:52 agentzh joined
pmichaud TimToady: are you actively working on list/iterator issues (in background), or should I keep plugging away at it? 01:55
01:56 cognominal joined 01:59 [particle]1 left 02:02 am0c left 02:05 kcwu joined 02:11 xinming_ joined, xinming left 02:16 lestrrat is now known as lest_away
colomon pmichaud: have you been pressing on with the other issues for list/iterator? It seems like the stuff we've been quibbling over is relatively minor... 02:18
pmichaud colomon: it's major. 02:23
colomon: it significally affects the structure of parameter passing, list context, function call returns, array construction, list assignment, ...
colomon I specifically meant the exact Iterator interface wrt .get versus .next / .value. 02:24
pmichaud even that.
colomon That seems like a small and easily changed detail compared to the rest of it.
02:25 spinclad joined
pmichaud except that the "rest of it" is intimately tied to the relationships between iterators and other classes 02:25
let me put it this way...
with this latest set of changes, I'm now on my _fifth_ implementation of arrays, lists, iterators, and the like, in eighteen months. 02:26
okay, more like 20 months now.
colomon wooof 02:27
that's a lot of rewriting.
pmichaud and not one of them has ever been a "minor detail". The smallest change in structure always requires a significant refactor of everything, and often results in a design spec change.
spinclad pmichaud: (backlogging) my .hasmore, .get example should read .next, .fetch , with .next buffering for .fetch (as in your design earlier). my using .get there confused the issue, .fetch was what i meant. 02:28
pmichaud spinclad: +1 02:29
thanks
at this stage I'm likely to start playing with a variety of implementation approaches (to see if any work) -- my question to TimToady++ was just to see if he was actively pondering things and likely to spring another set of spec changes in the next day or so 02:30
if yes, I'd probably wait for them; if no, then I'll just barrel ahead with my best guess at things
it would also help to know if he (or anyone else) had any specific leanings after today's discussions on the topic 02:31
ruoso++ was favoring an exception-based model
iirc, Tene++ was favoring a next/get model, but having it be somewhat implicit in the .Bool and .get methods 02:32
I'm currently thinking of .get as fundamental, with .next/.value to be able to have a bit more control over things. I haven't figured out how .get signals to the iterator itself "I'm done" (doesn't have to be a sentinal, as the .get could set a flag directly in in the invocant iterator) 02:33
other votes would be very welcome
02:35 TiMBuS joined
colomon pmichaud: you're thinking that when it runs out, .get can return Nil or something like that and set the flag, and the flag is what you use to check and see if you are done? 02:35
02:35 arnsholt_ is now known as arnsholt, orafu left 02:36 orafu joined
colomon I suppose Mu might be better than Nil.... 02:36
arnsholt A sentinel value would preclude storing that value in the underlying list/collection 02:38
But it's also the most convenient in a lot of cases
Hard to make a decision 02:39
pmichaud (on phone) 02:40
02:40 stephenlb left
Tene pmichaud: I'm not attached at all to implicit in .bool/.get, I just find a sentinal value rather distasteful, granting I might isunderstand how Nil is special. 02:41
02:42 niros_ joined 02:43 sjohnson sets mode: +o Tene 02:47 sundar joined 02:48 xinming joined, LaVolta left, lest_away is now known as lestrrat, xinming_ left, LaVolta joined
spinclad for the sake of discussion i suggest calling the two-block/two-continuation interface .get2: $stream.get2( -> $_ { .useit }, { ... #`($stream is done) ... } ) # no sentinal, no buffering 02:52
02:54 niros left
spinclad you can look at the two blocks/continuations as a single multi continuation (where's the syntactic support for that?) 02:54
colomon spinclad: are you proposing the blocks ought to be passed to the iterator? :O 02:57
spinclad and at that as a variant (.getM, say, for the moment) that returns a Maybe Value (in haskell term) to a destructuring case switch:
colomon: no, to the get2 method 02:58
colomon spinclad: of the iterator, though, right?
spinclad yes
it's like continuation passing style 02:59
03:01 drbean joined
colomon It seems like something you'd do in Factor rather than in Perl. (But, you know, Factor is way cool.) 03:02
I'm trying to code up toy examples, just to get a feel for what these things would be like. 03:03
Anyone have a notion whether you'd be allowed to call .value once .next returned false? 03:04
spinclad (... case switch:) (warning, pidgeon haskell) let $maybe = getM $stream in case $maybe of Maybe $value: use $value; Nothing: # $stream is done
colomon I'd be cool with that last one, I think, in a more perl 6ish version.
spinclad in Haskell, aiui, the whole building and tearing down the Maybe gets compiled away. when Perl 6 is farther along and can do that, well, much happiness... 03:06
colomon: me too.
at the moment, though, i don't see a way to compile away the Maybe layer, so at runtime it would carry a lot of overhead. 03:07
something to work for on the longer term.
colomon: once .next returns false, .value might fail. 03:08
colomon if calling .value at that point is forbidden, it actually simplifies things quite a bit. :) 03:09
spinclad (but can you tell that failure from a value whose domain happens to be Failure?) 03:11
(i keep thinking of my $b = Nil #`(or whatever Sentinal is used); for ($a, $b, $c) { #`(does this ever see $c, or even $b?) } 03:13
)
colomon TimToady's theory is that $b just disappears if you do that. 03:14
spinclad it should if it were @b, but not for $b: $b is a single value, not none, and not end-of-list. 03:15
and wouldn't for see $b as end-of-list and quit prematurely, never getting to $c? (like \0 in c strings: the same pathology.) 03:17
03:18 pnate joined
pmichaud colomon: I think that calling .value should be valid -- and it should return the "beyond the end of the iteration" value 03:19
(whatever that happens to be)
colomon I think the idea would be that whatever generates the iterator from $a, $b, $c would do the absorbing of $b.
pmichaud no, my $b = Nil causes $b to be Mu
because Nil in item context becomes Mu
it's not possible to store Nil in a variable
colomon pmichaud: calling .value after the fact would make implementing .value more complicated. 03:21
pmichaud why?
.next sets the value to be used the next time .value is called.
colomon hold on, I'll post an example. 03:22
03:23 hicx174_ joined
pmichaud for reference: 03:23
my $b = Nil; for (1, $b, 3) { say $_.WHAT; } # Int, Mu, Int 03:24
spinclad pmichaud: how about my $b = \Nil? is that already something besides the evanescent Nil itself?
TimToady Parcel(Nil) is not the same as Nil
spinclad ng: my $b = Nil; say $b.WHAT
ENOP6BOT? 03:25
pmichaud looks like ng currently gets it wrong anyway (not surprised)
colomon I think my $.code calling is a bit wrong, but the point should come through: gist.github.com/286514
afk (rocking son) 03:26
TimToady I think I'd be okay with changing Nil to mean something more like () xx *
making it more suitable as an end marker 03:27
pmichaud how would one check for Nil? still the macro?
TimToady it's primitive enough to warrant a macro, methinks
03:27 pnate2 left
TimToady it has to be magical somehow 03:27
it's sort of the only object that isn't an object, as it were 03:28
03:28 jaldhar joined
TimToady an iterator that is guaranteed always to produce nothing 03:28
03:29 araujo joined
pmichaud colomon: the first .next/.value example you have isn't good -- we don't want to invoke $.code on each request for .value 03:29
we want to invoke it once, at the time the value is generated
colomon: but more to the point, I'm thinking the .next/.value semantics belong in the Iterator role (or something that does iterating), and not in each individual iterator type 03:30
i.e., MapIterator shouldn't have to implement a .next/.value because it's already supplied by the role. MapIterator just needs a mechanism to "get the next value"
03:30 dean-ero joined
pmichaud (TimToady: this discussion about .next/.value is highly speculative still -- waiting for some guidance from you :) 03:31
TimToady what is .value?
pmichaud perhaps the best explanation is to look at something like infix:<Z>
just a sec
gist.github.com/286214 # some examples I was playing with earlier 03:32
the problem with version #1 is that we can't always know that all of the iterators/lists can properly signal end-of-list before iterating 03:33
so, one possibility is to have an iterator do ".next" (iterate to the next value, return true if there is one, false if not) and ".value" (give back the value just iterated) 03:34
03:34 cognominal left
TimToady I'm opposed to eof-like solutions 03:34
Tene pmichaud: In that model, how can you check if the iterator is done without advancing?
pmichaud Tene: well, you can't. But that's true in any model, I think. 03:35
spinclad pmichaud: if you s/$.base-iterator/$.base-iterator.value/ in method value, i think it works. if you call .value several times at the same place in map's iterator, it uses the same .value of the base-iterator... (modulo side-effects? arguably they *should* run again?)
pmichaud Tene: wait, I phrased that wrong.
spinclad: they shouldn't. The result of "map" should be the result of applying the code block *once* to each value (unless a REDO exception occurs) 03:36
spinclad pmichaud: (re colomon's example)
pmichaud spinclad: yes, I was working from colomon's example.
TimToady me feeling is that pushback ought to cover all needs to peek ahead
spinclad in which case map will call .value once at each position, and all's well
maybe 03:37
pmichaud spinclad: you're assuming that map is the only thing that would call/use MapIterator, I think?
spinclad a moment while i reread... 03:38
pmichaud TimToady: so, in the case of infix:<Z>, you're explicitly saying that we should use something like the third version?
i.e., where we go ahead and call .get and check for receiving Nil?
spinclad pmichaud: yes i am
pmichaud spinclad: I'm not sure that we can/should assume that any Iterator object has exactly one driver.
TimToady the first versions will tend to be full of race conditions 03:39
our iterators need to deal with backends that can't back up, and need pure gimme-what-you-got-right-now interfaces 03:40
pmichaud TimToady: fair enough. Those are reasons I can cope with.
TimToady the only way to guarantee those kinds of backends work right is never to ask if they're ready, if there's a way to just try to read
much like we almost always discourage people from using eof in p5
just read the filehandle
spinclad actually, i think, map doesn't call .next or .value, but just passes out a MapIterator, and the consumer .next/.value's it... so it's up to a third party. but if the third party wants to dwell on a spot .valuing it, what should happen? unspecced? 03:41
pmichaud spinclad: I think that .next of the map iterator should apply the block to the value, and store it.
spinclad yes, that's another model, and i think i agree, better. 03:42
03:42 pnate left
pmichaud TimToady: okay, I follow the reasons for wanting .get-returns-Nil a bit better now 03:44
(and I can agree with them) 03:45
I'll play with a few designs and see if I can better discover what we want Nil to really be
TimToady and if Nil is magicaller than (), this also improves things from your view, I suspect
pmichaud in some sense, Nil still wants to be a type :-)
that helps make it magicaller :-) 03:46
TimToady well, it's really a junction: none(Mu) :)
pmichaud have you had a chance to read backscroll yet? 03:47
TimToady just started 03:48
pmichaud just in case there are some other ideas there that you might want to incorporate
I kind of like the notion of "interesting values of end-of-iteration"
it may be overkill/unnecessary, but in some ways it seems to fit 03:49
TimToady interesting values of end of iteration are generally quite exceptional, I'd think
pmichaud anyway, if you see anything there worth considering, let me know. otherwise, I'm going to go with a get-returns-Nil based model and also suspend my preconceptions of what "Nil" is internally to see what can be made to fit its requirements 03:50
TimToady so I'd just be inclined to throw 'em, and not try to pass 'em in-band, esp if that slows down the is-nil test
pmichaud well, I'm thinking that in that case, the is-nil test could be a typecheck 03:51
i.e., we test for something that matches the "end of iteration" type
TimToady I'd rather keep it a simple value if possible
pmichaud fair enough.
03:52 cognominal joined
pmichaud so, what are the constraints on Nil? It needs to be something that disappears in list context, and becomes Mu when used like an item. Anything else? 03:52
TimToady since we're going to be iterating iterators at many laziness levels, this has to be a blazing fast test
pmichaud yes, and checking for Nil at the moment isn't a blazing fast test
unless it becomes its own type or something easily distinguishable from other things 03:53
TimToady it doesn't have to disappear in a list if it can never appear in a list
it merely has to terminate a sublist without terminating a superlist
pmichaud that's an interesting concept 03:54
TimToady it's not () anymore
pmichaud well, what would it be in \(1, 2, Nil, 4) ?
TimToady that returns 1,2
say 1, 2, (), 4 to mean the other thing 03:55
if we separate those concepts
pmichaud then \(1, 2, foo(), 4)
and sub foo() { return; }
TimToady can return Parcel()
that's not Nil
pmichaud okay, so...
an empty Parcel is removed in list context, and becomes Mu in item context 03:56
but an empty Parcel isn't Nil
spinclad so sub foo() { return Nil; }
pmichaud (which is a significant departure from what Nil has been previously)
TimToady not much
that returns Parcel(Nil), which is Parcel()
03:57 xinming_ joined
pmichaud I've always understood Nil to be the "undef in item context, empty list in list context" thingy, even before it was () 03:57
spinclad got it, just worked that out for /me
pmichaud I'm fine if () is now that thingy
(I'm very fine with that, btw.)
(as in, I like that *much* better.) 03:58
colomon sounds like we are getting somewhere, \o/
TimToady for Christmas, I got Umberto Eco's book: the Infinity of Lists :) 04:00
04:00 sundar left
pmichaud .... if 04:01
sub foo() { return Nil; }
is the same thing as
sub foo() { return (); }
....then how do we have an iterator return Nil? ;-)
TimToady return from the gather? :P 04:02
pmichaud is that meant seriously or as in "I don't know..."
?
TimToady we could perhaps special-case return Nil for that purpose
pmichaud okay.
"I don't know..."
(wasn't sure how to interpret the :P ) 04:03
TimToady though returning from gather does have that effect
pmichaud right
TimToady the joke was to force everything to use gather/take
pmichaud right
which has its own set of performance issues :)
TimToady including, presumably the implementation of gather :)
pmichaud and we *still* haven't resolved exactly how we want to deal with gather { my $a = 0; for 1..5 { take $a; $a++; } } 04:04
TimToady a function with a declared return type doesn't have to return a Parcel
that might or might not mean anything 04:05
being hauled off, bbl & 04:06
pmichaud okay
thanks for the ideas... I'll play with it a bit more
04:06 justatheory left
pmichaud TimToady: (opinion sought) --- my reading of the current spec prose is that there are a lot of places where "Nil" is really being used to mean "empty Parcel". So much so that it makes sense to have a name for the empty Parcel, such as "Nil" (more) 04:13
So, if that's the case, and if the empty Parcel/Nil doesn't work out well as an iterator sentinel, perhaps we should go ahead and designate some other value or special thing as the end-of-iterator sentinel? 04:14
04:15 xinming left
pmichaud (just a thought... maybe playing with implementation a bit more will yield some more clues.) 04:15
spinclad fwiw, here's a variation on infix:<Z> using a small variation on the .get2 interface: gist.github.com/286535 04:17
(version 4 therein)
04:18 lypanov1 joined 04:20 jaldhar left 04:23 xinming joined
spinclad i'm unsure as yet how well .get2 composes or scales syntactically or semantically; i'm happy with it so far and want to pursue it further. 04:23
let me know if you look at it and see problems. 04:24
04:26 lypanov left
spinclad pursues clothes-washing & 04:29
cognominal pmichaud, I thought of a sngleton value that cannot be used for anything but comparing with itself.
04:30 xinming_ left
cognominal ... well it be usable for assignment too. 04:32
cognominal returns to his bed to try to get some sleep 04:34
04:55 drbean left 04:58 dean-ero left 05:07 xinming_ joined 05:12 frew is now known as frioux 05:13 mssm joined 05:24 xinming left 05:30 xomas left, am0c joined, am0c left 05:35 christine joined 05:38 xinming joined 05:44 xinming_ left 05:47 kcwu_ joined 05:49 eternaleye left 05:53 pnate2 joined 06:00 eternaleye joined 06:01 kcwu left 06:10 sundar joined 06:19 pnate2 left 06:34 cognominal left 06:49 cognominal joined 06:51 simcop2387 left 06:53 niros joined 06:56 k23z__ joined 07:04 niros_ left, jonasbn joined 07:07 am0c joined, am0c left 07:10 simcop2387 joined 07:11 kaare joined, kaare is now known as Guest4236 07:32 Su-Shee joined
Su-Shee good morning 07:33
07:52 Baggiokwok joined 08:02 iblechbot joined 08:10 Guest4236 left 08:11 Guest4236 joined, [particle]1 joined 08:16 pnate joined 08:22 ejs joined 08:25 renormalist joined 08:28 cognominal left, cognominal joined, [particle] left 08:30 rgrau joined 08:33 drbean joined 08:34 niros left 08:35 ejs1 joined 08:36 cj_ joined 08:38 cj left 08:41 am0c joined 08:43 LaVolta left 08:44 ejs left 08:52 cognominal left, cognominal joined 09:09 dakkar joined 09:19 drbean_ joined, tkr left 09:24 Baggiokwok left 09:26 drbean left 09:38 c9s left, c9s joined 09:39 payload left 09:48 lumi joined
moritz_ good morning 09:51
09:51 rgrau left 09:52 rgrau joined
moritz_ just added a link to fedoraproject.org/wiki/Features/Rakudo_Perl_6 to the how-to-get-rakudo site 09:57
gerd++
09:59 meppl joined 10:00 payload joined 10:06 drbean_ left 10:10 Mantis left, bryan_ joined
jnthn morning 10:13
moritz_ good morning 10:14
10:19 lumi left, lumi joined, payload left 10:20 cognominal left 10:22 payload joined 10:26 lestrrat is now known as lest_away, lypanov1 left
mberends goes very offline, to work() on asp.net training 10:30
10:30 mberends left
moritz_ have fun 10:30
10:36 xinming_ joined 10:48 agentzh left 10:50 payload left 10:51 lest_away is now known as lestrrat, payload joined 10:53 mikehh left, lumi left 10:54 lumi joined, xinming left, mikehh joined 11:09 renormalist left 11:31 xomas_ joined 11:33 xomas_ is now known as xomas 11:35 lichtkind joined 11:38 drbean joined 11:39 lumi left 11:40 lumi joined, Baggiokwok joined 11:45 cognominal joined 11:46 payload left 11:47 rjh joined 11:50 cls_bsd left 11:53 Baggiokwok left 12:08 LaVolta joined 12:09 Baggiokwok joined 12:11 mikehh_ joined, mikehh left 12:12 bryan_ left, lumi left, cls_bsd joined
colomon morning! 12:13
moritz_ \o/ 12:14
12:14 lumi joined, payload joined 12:15 slavik joined
lichtkind :) 12:16
12:16 bluescreen joined 12:20 am0c left 12:42 rjh left 12:43 rjh joined
cognominal happy birthday jnthn 12:47
jnthn cognominal: Thanks! :-) 12:48
12:48 lumi left, lumi joined
moritz_ jnthn++ 12:48
erm
jnthn.age++
or so :-) 12:49
12:49 SmokeMachine joined
frettled ooh. 12:49
jnthn: congrats, may there be hundreds of more years in good health! 12:50
and since you're so young, you have a good chance for medical science to make you live for hundreds of years, too ;)
jnthn hundreds? sheesh, I might even get to see Perl 8! 12:51
frettled now now, let's not exaggerate ;)
jnthn OK. Maybe 6.6.6. :-) 12:52
frettled :)
I was going to suggest Perl 7, but...
colomon happy birthday!
12:53 mikehh_ left 12:54 jaldhar joined, mikehh_ joined 13:02 ignacio_ joined 13:05 lumi left
pmichaud good morning #perl6 13:07
13:08 lumi joined
pmichaud "Hundreds? Oh, so there's a small chance you'll see Perl 6 in your lifetime." :-) 13:08
13:09 takadonet joined
takadonet morning all 13:09
13:11 mikehh_ left, mikehh_ joined
sjn o7 13:18
pmichaud: do you know of any short and high-signal "sales texts" for perl6/rakudo? 13:19
short, as in < 100 words
pmichaud sjn: not off the top of my head. might look at perl6.org and see if there's anything there
sjn not really 13:20
a couple of us that are going to FOSDEM (Brussels, Feb 4-6)
...are going to set up a Perl stand there 13:21
frettled sjn++ :)
sjn basically see if we can't make Perl projects a little more visible
so we're trying to write some texts for flyers/postcards and such
TPF is putting some money into this too, luckily 13:22
any pointers would be helpful :) 13:24
this is what we have now: 123.writeboard.com/470b8ce9d41307670 (pw is "") 13:25
still work-in-progres
+s
as you can see, Perl6/Rakudo needs more representation 13:26
pmichaud afk # kids to school 13:35
13:40 sundar left, lumi left 13:41 lumi joined, payload left
jnthn afk # slovak 13:43
13:43 payload joined
slavik ? 13:49
13:51 payload left, payload joined 13:53 go|dfish left 14:05 [particle]1 is now known as [particle] 14:10 LaVolta left, araujo left 14:11 tkr joined 14:15 ignacio_ left 14:22 TiMBuS left 14:24 ignacio_ joined 14:25 am0c joined 14:32 ignacio_ left 14:38 lumi left, lumi joined 14:40 payload1 joined 14:42 mj41 joined 14:47 ignacio_ joined, payload left, partisan left
pugs_svn r29586 | pmichaud++ | [pm.txt]: Added Pm-19 for TimToady++ or others to answer. 14:52
r29586 |
r29586 | Pm-19: In each statement below, how many times is the block argument
r29586 | to .map() executed?
r29586 |
r29586 | my @b = (1,2,3 Z 4,5,6).map({ ... });
r29586 | my @@c = (1,2,3 Z 4,5,6).map({ ... });
14:52 Guest4236 left
pugs_svn r29586 | my ($x, $y, @@z) = (1,2,3 Z 4,5,6).map({ ... }); 14:52
colomon pmichaud: doesn't that depend on the arity (er, count?) of the block? 14:53
pmichaud assume the block has arity 1
moritz_ I guess a default of 1 is assumed
pugs_svn r29587 | pmichaud++ | [pm.txt]: Add arity/count assumption to Pm-19 (colomon++) 14:54
colomon sincerely hopes the answer is the same in all three cases....
pmichaud colomon: and what answer would that be? ;-)
colomon pmichaud: my instinct is 6, but I'd be cool with 3 in a pinch. 14:55
I just don't want what's on the left side of the = influencing the answer.
pmichaud oh, that sort of thing happens already, though. 14:56
colomon I feel strongly that that way lies madness....
moritz_ that's what context is
14:58 mj41_ left 15:01 cotto_w0rk joined, fda314925 joined
colomon But those examples are simple. What if it is something like my @@c = (1, 2, 3 Z 4, 5, 6).map({...}).grep({...}).sort.uniq ? tracing back through three functions to figure out how map is supposed to work in the @@c context..... 15:01
15:02 kcwu_ left
pmichaud colomon: the examples aren't actually that simple. but knowing the answers to those examples would likely tell me the answers to the others. 15:02
15:07 drbean left 15:08 hicx174_ left 15:09 kcwu joined
colomon s/those examples are simple/those examples could be much, much crazier/ 15:09
pmichaud anyway, I think the short(est) answer to your question would be that .map wouldn't need to know about @@c directly -- it would use the context supplied to it by .grep (which uses the context supplied to it by .sort, which uses the context supplied to it by .uniq, which uses the context supplied to it by the assignment). 15:10
however, I agree that this might be somewhat problematic -- it starts to look like the want() issue again.... which is one of the reasons I'm explicitly posing the question in pm.txt :) 15:11
colomon seems like that would require allowing multi methods to overload on context?
pmichaud no, not necessarily. the various iterators and flatteners would just need to know what context(s) to use 15:12
15:12 payload1 left
colomon Hmmm, just to make sure I'm tracking properly -- the idea here is that @@c might want a list of lists rather than a flattened list, right? 15:14
moritz_ right
PerlJam good day #perl6
colomon but doesn't it become an issue then what map's block actually does? maybe it maps single numbers to lists....
pmichaud ...that's one reason why these "simple" examples aren't so simple. :) 15:15
and no, I hadn't thought of that case, which itself is a compounding issue :-)
colomon++ 15:16
PerlJam colomon: why would the answer to Pm-19 be 6? 15:17
pmichaud PerlJam: .map could impose list context on its invocant.
PerlJam seems backwards to my intuition. 15:18
15:19 ejs1 left
pmichaud PerlJam: suppose I said instead: my @b = (foo14(), foo25(), foo36()).map( { ... } ); 15:19
colomon PerlJam: because conceptually (in my head, anyway), a map over a block with an arity of 1 wants to be fed a list of scalars.
pmichaud where each of foo?? returns a 2-element list
in that case, would you expect the lists to flatten, or no?
PerlJam I dunno. Perl 6 has my intuition from Perl 5 all cock-eyed :) 15:20
pmichaud and there's also the case of
colomon that is how it works in master, isn't it?
pmichaud my @b = (@foo[1,4], @foo[2,5], @foo[3,6]).map({ ... }); 15:21
colomon rakudo: (1, 2, 3 Z 4, 5, 6).map({ .say; $_ * 2; }).perl.say
pmichaud colomon: master is definitely not authoritative here -- it doesn't know anything about slices
colomon pmichaud: sure, just trying to justify where I might have gotten my intuitions on the subject. :) 15:22
PerlJam If we say that lists are always flattening, where's the difficulty with that?
pmichaud well, the reason I asked (and the reason for most of my questions in pm.txt) is because I can argue it several ways, so I need someone (TimToady++) to say which way is the "right" one
colomon (is dalek down? anyway, testing locally shows map's block gets called six times.)
pmichaud PerlJam: then how does one iterate over slices? 15:23
ng: say 'hello'; # I think p6eval is down
PerlJam pmichaud: is a slice a list?
pmichaud PerlJam: it's a list of lists
or one might say it's a list of captures 15:24
15:24 p6eval joined
moritz_ pugs: say 1 15:24
p6eval pugs: 1␤
moritz_ rakudo: say 'foo'
p6eval rakudo 1d4928: foo␤
diakopter moritz_: thanks for recovering that
moritz_ diakopter: I just killed the process :-)
diakopter oh 15:25
PerlJam pmichaud: what exactly do you mean by "iterate over slices"? (I can read that 2 ways)
colomon rakudo: (1, 2, 3 Z 4, 5, 6).map({ .say; $_ * 2; }).perl.say
p6eval rakudo 1d4928: 1␤4␤2␤5␤3␤6␤[2, 8, 4, 10, 6, 12]␤
pmichaud PerlJam: process a slice one capture at a time, instead of flattening the lists
15:25 araujo joined
pmichaud colomon: note that the example you give is in list context anyway :-) 15:25
colomon :) 15:26
How does that work, actually? Can you restate it in some other context?
pmichaud ...how does what work? 15:27
PerlJam pmichaud: What's the relationship between captures and lists? Because captures are fairly atomic now (non-flattening) unless we pass them through a |-prefix right?
(or maybe I have that backwards)
colomon pmichaud: how does my example get list context?
15:28 araujo left
colomon If I try to reason backwards, .perl mucks things up, because it takes *something* and returns a Str. 15:29
15:29 cotto_work left
pmichaud colomon: oh, that's a good question. The .say is in void ("sink") context 15:29
15:29 araujo joined
pmichaud the .perl will impose item context on its invocant 15:30
15:30 araujo left
pmichaud short answer -- I'm not at all sure what happens here, because contexts and slices are a bit fuzzy here (thus my question :-) 15:31
PerlJam: Captures are non-flattening, correct.
(unless explicitly flattened with |)
PerlJam so a list of captures is as flat as it's going to get without some prodding by the programmer, so this would be "simple iteration" :) 15:32
15:32 araujo joined
pmichaud oops, I mis-stated 15:32
Captures are non-flattening in slice context, they're flattening in list context
PerlJam Way off topic, but does anyone happen to know the website that has tech docs or podcasts or something for $9? I forget it's name. 15:33
15:34 ejs joined
PerlJam Hmm. so the difference between "slice context" and "list context" is just that the latter flattens and the former does not? 15:36
pmichaud PerlJam: yes, I think so.
15:37 uniejo joined, araujo left 15:38 araujo joined
jnthn pmichaud: Is the latest still that "to enforce a context call a method" holds? e.g. to put in list context, call .list? 15:38
jnthn is trying to keep up and failing
Would that imply a .slice?
pmichaud jnthn: no
jnthn And Parcel would know what to do?
OK
pmichaud .list does not mean "put in list context"
it means "return yourself as a list"
here's the difference 15:39
my $a = [1,2,3];
my @b = [1,2,3];
oops
drat
my $a = [1,2,3];
my @b = 1,2,3;
both $a and @b are Array with 3 elements
$a in list context does not flatten, while @b in list context does flatten
jnthn Right.
OK
pmichaud however, $a.list has three elements 15:40
jnthn So what does "put something in list context" actually mean at this point, or is that still an unknown?
pmichaud list(...)
PerlJam jnthn: to put an expression in a particular context, you'd use a contextualizer: item foo(), hash foo(), list foo(), slice foo()
pmichaud say list($a).elems # 1
say $a.list.elems # 3
jnthn OK, and list(@b) would flatten? 15:41
pmichaud yes.
jnthn Right.
pmichaud say list(@b).elems # 3
jnthn my @a = 1, (2, 3), 4;
my @b = slice 1, (2, 3), 4; 15:42
say @a.elems; # 4 ?
pmichaud yes