»ö« | 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.
pmichaud TimToady: are you actively working on list/iterator issues (in background), or should I keep plugging away at it? 01:55
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.
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
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
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
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
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
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
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
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
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
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
TimToady an iterator that is guaranteed always to produce nothing 03:28
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"
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
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
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.
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()
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
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
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
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)
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
spinclad pursues clothes-washing & 04:29
cognominal pmichaud, I thought of a sngleton value that cannot be used for anything but comparing with itself.
cognominal ... well it be usable for assignment too. 04:32
cognominal returns to his bed to try to get some sleep 04:34
Su-Shee good morning 07:33
moritz_ good morning 09:51
moritz_ just added a link to fedoraproject.org/wiki/Features/Rakudo_Perl_6 to the how-to-get-rakudo site 09:57
gerd++
jnthn morning 10:13
moritz_ good morning 10:14
mberends goes very offline, to work() on asp.net training 10:30
moritz_ have fun 10:30
colomon morning! 12:13
moritz_ \o/ 12:14
lichtkind :) 12:16
cognominal happy birthday jnthn 12:47
jnthn cognominal: Thanks! :-) 12:48
moritz_ jnthn++ 12:48
erm
jnthn.age++
or so :-) 12:49
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!
pmichaud good morning #perl6 13:07
pmichaud "Hundreds? Oh, so there's a small chance you'll see Perl 6 in your lifetime." :-) 13:08
takadonet morning all 13:09
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
jnthn afk # slovak 13:43
slavik ? 13:49
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({ ... });
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
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
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
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
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
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
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
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?
colomon If I try to reason backwards, .perl mucks things up, because it takes *something* and returns a Str. 15:29
pmichaud colomon: oh, that's a good question. The .say is in void ("sink") context 15:29
pmichaud the .perl will impose item context on its invocant 15:30
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
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
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.
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
jnthn say @b.elems # ??
pmichaud @b.elems would also be 4, I think :)
jnthn Because the my @b = ... is a list assignment and implicitly forces list context ont he RHS?
*on the 15:43
pmichaud because a capture in list context flattens
jnthn Thus the "slice" is useless in what I wrote, essentially?
pmichaud yeah, to store a slice one would need @@b 15:43
my @@b = slice 1, (2,3), 4; say @@b.elems # 3
jnthn my @@b = 1, (2,3), 4; # 3 or 4? 15:44
pmichaud 3
jnthn :-/
jnthn oh, sorry 15:44
That was the answer I wanted :-)
pmichaud @@b = is slice assignment, not list assignment
jnthn Right.
I braino-d.
pmichaud ($a, @@b) = .... would be list assignment :-)
jnthn my @b; my @@b; # ok or error?
pmichaud error
no
jnthn OK.
pmichaud not error 15:45
jnthn ?
pmichaud two different vars
my $b; my @b; my @@b; my %b;
jnthn OK, so @@ is a sigil?
pmichaud yes, @@ is a sigil 15:45
jnthn @@b is not just an alternative view of @b?
OK.
pmichaud token sigil:sym<@@> { <sym> }
(from STD.pm)
jnthn OK, I hadn't appreciated that part.
I'd somehow thought @@ was just another view of... 15:46
OK, so we have item, list, slice and hash contexts?
pmichaud and sink 15:46
jnthn Ah, ok.
PerlJam still thinks "void" when he sees "sink"
jnthn "I just poured my cold coffee into the void!" does sound SO cooler. :-) 15:47
pmichaud: OK, I think I follow the slice thing a bit more now. :-) 15:48
pmichaud "loose lips void ships" # hmmmmmm
jnthn lol!
pmichaud "Perl has everything, including the kitchen void" 15:49
PerlJam And don't even ask about "everything and the ... damn you pm! :-)
jnthn pmichaud: Dare I ask about the iterator stuff? Or should I find time to backlog later? :-) 15:50
PerlJam So ... if I'm reading S03 correctly, then @@b = 1, (2,3), 4; makes @@b look like [1],[2,3],[4] right? 15:50
jnthn (Gotta head out in a little bit...)
pmichaud PerlJam: more like \1, \(2,3), \4
jnthn: I'm still working away on it, but had to add a new Pm-19 to pm.txt 15:51
short answer is that TimToady++ has some good reasons for wanting a sentinel-based approach to end-of-iterator
jnthn OK.
pmichaud so, I'm heading in that direction.
PerlJam Well, I was reading about @@() and I assume it applies to "slice assignment" the same: say @@(<a b> X <1 2>) # ['a', '1'], ['a', '2'], ['b', '1'], ['b', '2']
S03:4726 15:52
pmichaud PerlJam: yeah, I'm not sure what to think there.
Because if a slice is a list of captures, but captures flatten in list context, then....
jnthn OK, and the exact nature of the sentinel is still being determined?
pmichaud: Maybe a slice is a parcel of captures? 15:53
pmichaud jnthn: correct. And it's possible that "Nil" will not be "()", or that the sentinel will not be Nil.
PerlJam pm: where does it say a slice is a list of captures?
jnthn pmichaud: OK, thanks for the updates. That saves me epic backlogging. :-) 15:54
pmichaud okay, that's not precisely correct
TimToady more like a list of parcels, I think
pmichaud PerlJam: a slice become a list of non-flattening lists
that would be a better way to say it
TimToady sincerely hopes his day is less crazy than yesterday 15:55
pmichaud basically, slice turns off the flattening nature of any of the nested lists
pmichaud so that in list context, they no longer flatten 15:55
PerlJam This becomes a flat list in C<@> context and a list of arrays in C<@@> context" @@ context is the same as slice context, yes? 15:57
pmichaud yes.
cottoo jnthn, happy birthday! 15:57
TimToady if we consider take to be fairly fundamental, it means whether take 1,2,3 keeps 1,2,3 together as [1,2,3] or flattens into 1,2,3 15:57
jnthn cottoo: Thanks! :-)
TimToady looking at it from the user end, it's in there mostly for multidimensional subscripting: @a[1,2,3; 4,5,6] 15:58
pmichaud TimToady: fossil at S03:2740?
$a = list 1, 2, 3; # force grouping using listop precedence
$a = @ 1, 2, 3; # same thing
pmichaud (does the @ require a paren?) 15:58
TimToady yes 15:59
std: $a = @ 1, 2, 3;
p6eval std 29587: ===SORRY!===␤Anonymous variable requires declarator at /tmp/FpFZALNOqz line 1:␤------> $a = @⏏ 1, 2, 3;␤ expecting twigil␤Other potential difficulties:␤ Variable $a is not predeclared at /tmp/FpFZALNOqz line 1:␤------> $a⏏ = @ 1, 2,
..…
pmichaud same at S03:2750
anyway, correct -- slice context basically affects the flattening of list elements in the slice 16:00
so, to go back and restate things from earlier 16:01
TimToady it's anti-flattening, in the sense that the conjectural groupings are no longer conjectureal
pmichaud my @b = slice 1, (2,3), 4; # @b.elems == 3
PerlJam needs a Capture, Parcel, Slice, List, Array redux 16:03
pugs_svn r29588 | lwall++ | [S03] fossil dug up by pmichaud++
pmichaud PerlJam: we're still working those out a bit. I'm fairly confident of Array and Parcel. :-0 16:04
TimToady you can mostly forget about Capture, which is just a Parcel sorted out into positional vs named args 16:06
(unless, of course, you're implementing it :) 16:07
pmichaud and a slice is basically a List with non-flattening elements 16:08
colomon TimToady: on that latest patch: @a[$ foo()] = $(bar()); should there also be parens around foo() ?
TimToady of course
blood hasn't hit the coffee stream yet 16:09
colomon is now imagining TimToady as a coffee-adicted vampire.... 16:09
pugs_svn r29589 | lwall++ | [S03] braino on previous patch
moritz_ is anybody opposed to deleting docs/Perl6/FAQ/Capture.pod in the pugs repo? 16:11
it seems very out of date
pmichaud void it
sink it
moritz_ sunk :-)
pugs_svn r29590 | moritz++ | delete very outdated Capture FAQ
pmichaud moritz_++
moritz_ cdn.shopify.com/s/files/1/0016/9762...od1920.png (very off-topic, but somehow I still had to think about Perl 6) 16:13
TimToady hmm, no hugme to give a creepy hug to moritz++ 16:19
moritz_ seems to have been lost in a netsplit 16:19
TimToady hugme: hug moritz++ creepily 16:21
hugme hugs moritz++ creepily
jnthn hugme: hug me adverbially
hugme hugs jnthn
jnthn aww!
TimToady you didn't smile right
hugme: hug jnthn adverbially 16:23
hugme hugs jnthn adverbially
jnthn \o/ 16:24
hugme: That was a SO adjective hug!
Time to go and celebrate getting a year old...back later/tomorrow. :-) 16:25
TimToady have the appropriate amount of fun
colomon and an inappropriate amount of beer. 16:26
TimToady thinks about chow fun
colomon is that what -Ofun is all about? 16:27
TimToady beats colomon with a wet noodle
colomon Is it a saucy noodle? I'm getting kind of hungry... 16:28
jnthn augment grammar P6 { token routine_declarator:chow { <sym> <routine_def> } }; chow Main() { } 16:32
<- really gone now :-)
diakopter mmm chow mein 16:37
TimToady pmichaud: given how Failure can be either in-band or out-of-band in Perl 6, I think we should probably use some particular Failure as the sentinel, like Failure() 16:51
pmichaud TimToady: yeah, that seems reasonable to me 16:52
TimToady then people can write in 'use fatal' style if they want
pmichaud I'm not sure I understand that last part ('use fatal')
TimToady and since Failure() is both a type and a singleton value, we can optimize
when a sub-iterator terminates with fail; it throws and exception instead of returning Failure() normally 16:53
pmichaud given that lists in general are pretty common, won't that cause lots of exceptions for even normal list semantic type thingies? 16:54
TimToady not sure how that interacts with gather/take though
pmichaud I mean, even a simple say @list; could end up throwing an exception
TimToady normally we'd use the Failure() as a sentinal value
maybe that depends on whether the implementation of say does 'use fatal', not the current scope 16:56
pmichaud ...I thought things like 'use fatal' were dynamic, though.
and it's not really the say() that would be imposing fatalness or non-fatalness, but whatever say uses to iterate its slurpy argument list 16:57
TimToady use fatal is lexically scoped
fail looks up at the caller to see what it says
in the caller's lexical scope
pmichaud just one level of caller?
TimToady don't see how it could work otherwise 16:58
pmichaud okay, that's fine.
pmichaud I didn't recognize that aspect of 'use fatal', but if that's how it works, no problem. 16:58
TimToady you have to write the code in your lexical scope with one assumption or the other
can't have your caller changing the meaning of your code that way
pmichaud anyway, a sentinel Failure works for me 16:59
TimToady OTOH, maybe Failure() doesn't give a good message
some some particular subtype of Failure
pmichaud yeah, subtype of Failure was where I had been leaning at one point
TimToady Nothing() or some such
pmichaud NoMore() :-)
TimToady AllGone()
pmichaud AllDone() 17:00
Done()
End()
Fini()
TimToady TheEnd()
It'sTheEndoftheWorldasWeKnowIt-andIFeelFine() 17:01
pmichaud Fine()
TimToady Credits() 17:02
pmichaud okay, I'll go with some sort of sentinel or special-typed sentinel and see how that works. Did you see the Pm-19 addition?
TimToady ENOTYET
pmichaud no problem -- I'm about to grab lunch.
there was some discussion of it in the backscroll also, around 14:51Z 17:03
pmichaud afk, lunch 17:06
TimToady colomon: In my house, you aren't allowed to cry over spilled milk, but you *are* allowed to cry under it. 17:11
colomon TimToady: a sensible policy. 17:28
[particle] jnthn: happy birthday! 17:38
ash_ so... jnthn and/or pmichaud and/or colomon, any of you noticed that loop in ng seems to require a ; after it? even when it doesn't seem like it should?
colomon I saw you mentioning it yesterday. 17:41
seems like it must be some sort of parser glitch?
ash_ yeah, i think it is (probably) a parser glitch
ng: eval("loop { say 'done'; last; };");
p6eval ng 7daa82: done␤Warning␤Null PMC access in get_string()␤current instr.: '_block14' pc 29 (EVAL_1:0)␤
ash_ ng: eval("loop { \n say 'done'; \n last; \n } \n");
p6eval ng 7daa82: Unable to parse blockoid, couldn't find final '}' at line 1␤current instr.: 'perl6;Regex;Cursor;FAILGOAL' pc 1664 (src/stage0/Regex-s0.pir:907)␤
TimToady ash_: did you ever find STD.pm? 17:42
ash_ TimToady: yes i did, thanks 17:43
I am starting a compiler independent study in a week-ish and i was going to show my professor some of the perl 6 things I have been working with / learning since the christmas break, the perl 6 grammar is pretty amazing IMO, it would be interesting to implement a parser capable of handling it, like pmichaud's nqp-rx, but i doubt i'd be able to (in any sort of reasonable timeframe) implement the grammar completely, but i might try doing parts of it in our study 17:45
colomon looks like loop is line 354 of Grammar.pm 17:48
PerlJam ash_: you mean loop requires a semicolon after the block even when it shouldn't?
That would be exceedingly weird. 17:49
colomon PerlJam: yet it is true. 17:51
PerlJam is building ng now to see
colomon Works okay if the loop is the last thing in the file, but if something else comes after, it fails.
without the semicolon, that is. with it's fine.
PerlJam weird 17:52
ash_ it gives the "Unable to parse blockoid" parser error if you don't have the ';' 17:54
colomon ash_: hmmm, I'm getting the "Confused at line blah" error here. 17:55
PerlJam too
ash_ what is the difference between <block> and <xblock> in the grammar?
PerlJam xblocks can be pointy I think 17:56
ash_ colomon: are you running t/spec/S04-statements/loop.t ?
colomon ash_: no, I just made a dead simple test file.
TimToady xblock is for an expression before a pblock 17:57
such as an if or a for
PerlJam ah, x for expression
ash_ colomon: can i see your example? and/or i can post mine
lisppaste3 colomon pasted "loop example" at paste.lisp.org/display/93942 17:58
PerlJam colomon: mine was just loop { say "hi"; last; } # :-)
colomon that's in working form, obviously, but easy enough to change.
PerlJam: oh sure, golf me. ;)
ash_ still, either way, those examples look perfectly valid to me 17:59
colomon oh sure, it's definitely a bug.
TimToady last I heard, ng was trying to parse without using a MEMO array, like STD uses
TimToady maybe it's necessary here 18:00
PerlJam looks at STD's statements 18:01
TimToady it's the stuff at the end of blockoid
ash_ i don't know the details, but if it can work for things like 'for' why wouldn't it work for 'loop'? just speculating...
TimToady specifically the endstmt memo 18:02
ash_ if you do <xblock(1)> whats the purpose of the (1) ? i am still learning how the whole grammar thing works :P 18:04
TimToady um, STD doesn't have that parameter 18:04
colomon ash_: it's passed in as $*IMPLICIT 18:05
not that I know what that does.
so maybe setting a flag which is normally 0 to 1?
TimToady maybe it's the difference between if and while on the handling of a bare block 18:06
while assumes -> $_ but if doesn't
TimToady I don't think STD cares about that distinction currently 18:06
ash_ well, for uses <xblock(1)> in ng, but while just uses <xblock> (same with if) 18:07
PerlJam aye, $*IMPLICIT == 1 seems to setup $_
TimToady sorry, I meant if and for 18:08
while is like if
PerlJam well, a true value for $*IMPLICIT anyway
ash_ it seems all the other statement_control tokens use xblock except loop
colomon PerlJam++ has it. line 160 of Actions.pm handles IMPLICIT. 18:09
PerlJam yep
ash_ no, i spoke to soon, default, CATCH, CONTROL statements use <block> as well
PerlJam ash_: default too 18:10
ash_ okay, got ya, so (1) wouldn't be the issue
PerlJam oops, you said that one
the gravity around CATCH an CONTROL was too great for me too see default :)
TimToady well, does default {} fail? 18:11
ash_ no, not for me
ng: given 5 {default {say 'hi';}} 18:12
p6eval ng 7daa82: hi␤
ash_ and its okay with whitespace and newlines around the { } too
PerlJam ash_: you don't even need a give to use default 18:13
er, *given
TimToady ng: given 5 { default { say 'hi'}␤say 'lo'}
p6eval ng 7daa82: hi␤
TimToady well, default needs to know where to succeed to
ash_ i know, i just like know where its going to return to
ng: default { say 'a'; } say 'b'; 18:14
p6eval ng 7daa82: Confused at line 1, near "default { "␤current instr.: 'perl6;HLL;Grammar;panic' pc 500 (src/stage0/HLL-s0.pir:328)␤
TimToady ng: default { say 'hi' }
p6eval ng 7daa82: hi␤
colomon oooo
ash_ did i spell something wrong? 18:14
colomon ng: default { say 'a'; }; say 'b';
p6eval ng 7daa82: a␤
TimToady ng default { say 'a' }␤say 'b';
ng: default { say 'a' }␤say 'b'; 18:15
p6eval ng 7daa82: a␤
colomon it is the same bug in this context.
ash_ ah
well then, it might be <block> related
TimToady eh, the semi above is necessary because there's no newline
PerlJam TimToady: I think you were on the right track with @*MEMOS and <endstmt>. Rakudo does something equivalentish, but different.
TimToady not because of the bug
if you put in newline with ␤ it works 18:16
PerlJam: or not equivalent
colomon TimToady++ is correct.
colomon blast, I thought we had a clue there. 18:16
TimToady is always correct, except when he isn't.
jettero I don't think my font is showing ␤ well... what is that meant to be? 18:17
ash_ a new line
jettero oh, I guess that's what it is, but it's really small
TimToady which bot does that?
TimToady u: ␤ 18:18
phenny: u: ␤ 18:19
must be misremembering
PerlJam didn't know that any of the bots were unicode-smart
TimToady there was one on here a month or so ago
jettero oic, it's a tiny little N and L in a big enough font. It looks kinda like a right arrow in my terminal font 18:20
TimToady the p6eval bot will translate it both directions 18:21
diakopter .u ␤
phenny U+0020 SPACE ( )
U+2424 SYMBOL FOR NEWLINE (␤)
TimToady that were it
jettero :) How do you type that btw? 18:22
diakopter copy/paste
jettero I can type things like — and ē with my compose key, but I can't find a sequence for ␤
TimToady I have a program that I can type to get it: 'u newline'
various input methods allow raw unicode input, if you know the hex code 18:23
gnome has a native one that I always forget
jettero I'm going to look for that immediately 18:24
ctrl-shift 18:26
TimToady CTRL-SHIFT-u
jettero yeah, the u
lichtkind moritz_: can i get some question time? 18:28
ash_ i like how in OS X you can just hold alt and get a limited set of unicode characters (like ¢ = option + 3) but you can switch input modes and do option + unicode number and it will put the character in 18:37
jettero I'm very fond of the compose key... it's still new for me. You can add things to it if there's characters you like, not on the list 18:39
I needed some way to type: I'm running perl 5.10 on my palm prē
ash_ so how would a *MEMO help with finding the end of the loop 18:47
pmichaud back from lunch 18:54
diakopter on Windows (since 3.1) you can Alt+0, codepoint on numpad
ash_ yay unicode support in all major os's
bsd probably functions the same as linux, if your using gnome, etc. i am sure
jettero I can't get the windows version to work, probably my terminal 18:55
or synergy
pmichaud the problem with "loop" in ng is likely related to the <.ws> 18:56
or perhaps the :s isn't properly scoped
lichtkind what was the end oft pugs hajdays end of 2007 ?? 18:57
pmichaud I'm guessing it's the :s 18:59
ash_: *MEMO isn't used for finding the end of the loop here -- the problem is that after finding the end of the loop, it's not detecting a valid statement terminator. 19:00
and that generally has to do with eating or not-eating whitespace at the end of the closing brace 19:01
ash_ ah, okay, i guess that makes sense
pmichaud so *MEMO (in STD) keeps track of where it's seen statement-ending curly braces
I have a fix... spectesting now
pmichaud pushed as commit 78e3b48 19:05
dalek kudo/ng: 78e3b48 | pmichaud++ | src/Perl6/Grammar.pm:
Fix statement termination with 'loop' statement control -- noticed
 19:06
ash_ cool, t/spec/S04-statements/loop.t probably works then 19:07
pmichaud it fails, redeclaration of $i
ash_ ah, it still has the list declaration issue then
pmichaud right
ash_ i can change the test to not rely on list declarations 19:08
pmichaud yes, changing that causes the test to pass.
(feel free to double-check and commit changes) 19:09
pmichaud If we use .get() on an Iterator to get a single element, is there a good name for a method on Iterators that could be used to retrieve (up to) $n elements? 19:13
.grab($n) ?
(For filehandles, we use .lines($n), but that doesn't seem to fit for a generic iterator.) 19:14
ash_ collect? 19:17
.collect(5)
pmichaud I thought of collect earlier, but didn't like it for some reason. although it seems better now. 19:18
Plus, if we do that then we can always call collect :-)
(sorry, bad pun)
PerlJam why not just .get($n) ? 19:19
ash_ .gimme(5)
pmichaud because it (currently) conflicts with .get on filehandles :)
I'm fine if .get accepts an argument
colomon what does .get($n) return? 19:20
PerlJam .lines($n) seems like it could be a synonym for .get($n) that just has the unit of iteration built-in for human convienence.
colomon: a list of $n things from the iterator.
pmichaud colomon: .collect($n) (or .get($n) if adopted) returns a parcel with the $n next elements from the iteration 19:21
colomon so is .get(1) equivalent to .get() or does it return a parcel with 1 element? 19:21
PerlJam If there's only 2 things left to iterate and we ask for 5 things from the iterator, do we get 3 Failure()s ?
pmichaud PerlJam: either that or just 2 elements 19:22
or 2 elements and 3 nils
I'd reserve returning Failure() for when nothing is returnable.
PerlJam colomon: yes :)
pmichaud in general, a parcel with 1 element is the same thing as the one element. 19:23
colomon pmichaud: ah
sorry, just trying to work through the ramifications of having the function which defines iteration return something which requires iteration. 19:24
PerlJam colomon: a parcel doesn't *require* iteration
colomon (or will a n element parcel have some other approach for examining its values)
PerlJam colomon: you just have to put it in the proper container or context
pmichaud basically, one possibility of map: 19:25
my $c = $iter.collect(&block.count); 19:26
last if $c ~~ sentinel;
&block(|$c)
modulo syntax and the fact that eventually we don't want to be using .count to figure out the number of arguments
ash_ so... that could be like $file.map -> $line_1, $l2, $l3, $l4 { } and have line_1 ... n ? 19:27
colomon pmichaud: shouldn't the test be more like "last if $c.elems != &block.count" ? (understanding that .elems probably doesn't work here)
pmichaud colomon: no, it's possible to call block with fewer than .count elements 19:28
(optional params, for example)
colomon rakudo: (1..5).map({ say $^a; say $^b; });
p6eval rakudo 1d4928: 1␤2␤3␤4␤
pmichaud that's a bug in rakudo 19:29
colomon k
pmichaud rakudo: (1..5).map( -> $a, $b? { say $a; say $b; });
p6eval rakudo 1d4928: 1␤Use of uninitialized value␤␤2␤Use of uninitialized value␤␤3␤Use of uninitialized value␤␤4␤Use of uninitialized value␤␤5␤Use of uninitialized value␤␤
pmichaud that should display 1 2 3 4 5 Mu()
pmichaud (with \n's) 19:29
colomon pmichaud: is the ? necessary or just polite? I guess I'm asking, if it weren't there, should it display 1 2 3 4 ? 19:30
pmichaud if the ? isn't there, then there should be a complaint about not enough arguments being sent to the block 19:31
pmichaud just as if one did 19:31
rakudo: (-> $a, $b { say $a; say $b; })(5)
p6eval rakudo 1d4928: Not enough positional parameters passed; got 1 but expected 2␤in Main (file src/gen_setting.pm, line 324)␤
colomon gotcha.
okay, sorry for the digression. 19:32
ash_ std: (-> $a, $b? { say $a; say $b; })(5)
p6eval std 29590: ok 00:01 108m␤
ash_ looks good to the std if you just use ?
PerlJam syntax isn't the problem.
pmichaud rakudo: (-> $a, $b? { say $a; say $b; })(5)
p6eval rakudo 1d4928: 5␤Use of uninitialized value␤␤
pmichaud okay, Use of uninit valud then :-) 19:32
pmichaud *value 19:33
I'll go with .collect($n) for now. 19:34
ash_ rakudo: (-> $a, $b? { say $a; say $b.WHAT; })(5)
p6eval rakudo 1d4928: 5␤Failure()␤
colomon pmichaud++ # .collect($n) 19:35
pmichaud desperatly wants to eliminate rakudo's master branch so that we don't see all of the places where it's become wrong
ash_ pmichaud++ # for trying to get things figured out so ng can be master 19:36
colomon wants to be able to say "ng is my master now." 19:42
pmichaud afk for a bit 19:43
ash_ how does rakudo-master deal with some of the issues like iterators? 19:44
PerlJam colomon: you could, on your local repo, delete master and rename ng to master. :)
colomon PerlJam: it wouldn't be the same.
PerlJam colomon: then perhaps you really want to be able to say "ng is our master now" :) 19:45
colomon fair enough. :) 19:48
TimToady it seems strange if $iterator.collect($n) just returns another iterator 19:50
for native types at least, you'd like to get a compact representation of those $n elements
and for other types, a Seq or Array of 'em 19:51
TimToady there has to be some reason you want $n of them all together, and I suspect that'll involve treating them out-of-order, which implies indexing 19:52
or some other reason for keeping the batch as a single object
(I'd prefer .getbatch over .collect, I think, just to emphasize the relationship with .get) 19:53
and to me, "collect" implies looking in random places 19:54
PerlJam TimToady: why not just .get($n) ? 19:55
TimToady because then the type of the return value is not constant
PerlJam .many($n) then? 19:56
TimToady maybe .getseq($n)
PerlJam getseq and getbatch seem to be encoding type information in the name when it should be a parameter IMHO 19:57
.get($n, Seq) # I'm stubborn :)
TimToady BLETCH
TimToady if anything is parametric, it's the type of each element 19:58
PerlJam yes, I agree with the sentiment, but getseq makes me feel the same way :)
true
(or maybe true :)
TimToady and getseq may be written quite differently from getarray 19:59
I think we also need to think hard about where we're baking in serial assumptions that we shouldn't 20:00
TimToady i.e. hyper map should not be implemented with a while loop 20:01
PerlJam tries to wrap his head around "non-linear" iterators 20:04
jettero "serial assumptions" as in: maybe it's on multicore? 20:07
or something fancier?
TimToady research.sun.com/projects/plrg/Publ...Steele.pdf 20:10
pmichaud I don't want $iterator.collect to return an iterator, it returns a Parcel 20:14
which can then be turned into a Capture (and that doesn't require iterating or flattening)
pmichaud I'm fine with .getbatch 20:15
jettero these slides are great. 20:16
PerlJam jettero: they were fine until he started speaking lisp :) 20:17
jettero heh 20:17
I may not get all the way through then 20:18
pmichaud I'm fine with .getseq also
pmichaud .getbatch is nice; I had been considering .batch some time ago, to also emphasize the "batch" nature 20:19
.getseq might imply that what we're getting back is a Seq, which really oughtn't be the case
PerlJam concludes that TimToady and pmichaud have some weird aesthetics
pmichaud PerlJam: yeah, we both like Perl 6. :)
PerlJam .getseq and .getbatch both make me retch a little. I could probably warm up to .batch though since it works in multiple conceptual dimensions. 20:20
pmichaud in some sense, they should make one wretch. We don't generally expect people to be using these directly :) 20:21
*retch
or *a wretch :-)
pugs_svn r29591 | pmichaud++ | [t/spec]: Remove unnecessary list declaration from loop.t . 20:22
TimToady have also been considering whether the done testing should be an ugly operator: take @iterators.>>get /// last 20:24
TimToady instead of a macro 20:24
(well, such operators are macros) 20:25
it's also possible we should be hijacking the existing orelse/andthen for this
pmichaud hmmm, hadn't thought of those. that's a possibility.
anyway, I've created a new branch ("ng1") for ripping-out/refactoring ng's current parcel/list/array stuff -- we'll see how far I get :) 20:26
TimToady since there's basically in there to process lists of continuations
dalek kudo/ng: b8201fd | pmichaud++ | t/spectest.data:
Mark t/spec/S04-statements/loop.t as passing.
colomon I dunno, I'd hesitate to add language-level support for using the iterators without some evidence that end-users were using them directly on a fairly regular basis. 20:27
TimToady the basic point of the Steele slides is that parallizable lists should be represented as trees that can subdivide the work in parallel
colomon: if you want to write the primitive operations in Perl 6, you have to have even more primitive operators to write 'em with 20:28
pmichaud since our lists are lazy, that sounds more like parallizable iterators
TimToady hyper lists are the opposite of lazy
they're a form of eager list 20:29
pmichaud okay, but to get to the eager list we often have to go through an iterator first
TimToady but we still have to be able to iterate those
colomon I thought we'd done away with the concept of hyper / eager lists?
pmichaud colomon: nafaik
TimToady who ever said that?
pmichaud I'm sure that @a >>+<< @b involves hyper lists :-) 20:30
colomon no one ever said it directly, but I thought the point of what we were doing is that lists are by definition lazy.
pmichaud "lists" plain, yes. but hyper lists are a different animal.
lists are lazy, unless eager or hyper :-) 20:31
TimToady at least two different defs of list here
list *context* is lazy
colomon I thought that @a >>+<< @b would be adding two Seqs, or something like that.
pmichaud (Seqs are lazy too :-) 20:32
TimToady can be lazy
just like Arrays
pmichaud right
colomon (BTW, I'm still somewhat tempted to allow @a >>+<< @b to be lazy... or to have an equivalent lazy concept, at least.)
TimToady well, it depends on whether the context of *that* wants it lazily, eagerly, or hyperly
but hyperops are already claiming you don't care what order they're done in 20:33
pmichaud I thought part of the point of >><< was to say that it could be hyperized
right
TimToady which kinda implies you'll eventually want all the values 20:33
regardless of which order you use them
that's why we say that hyper is a form of eager 20:34
pmichaud I've been very tempted several times in Rakudo to go make sure that >><< doesn't evaluate things in sequence
TimToady they're both run-to-completion semantics
pugs did that :)
pmichaud haven't done it yet, but I'm likely to do so 20:35
PerlJam pmichaud: after ng becomes master :)
TimToady pugs: (1,2,3)>>.say
p6eval pugs: 2␤3␤1␤
pmichaud PerlJam: yeah, the setback on lists/iterators this past weekend has definitely put me behind schedule. I'm trying to catch up. 20:36
(not behind schedule for Rakudo *, just behind schedule for my milestone)
colomon Right, I understand the benefits of having hyper. I'm just thinking there are potential benefits to having list-ops, too, like the ability to add two finite lists with a single operator.
s/finite/infinite/
I suppose it falls into the category of "easy enough to implement that you can do it in a module". :) 20:37
TimToady it might fall out from the S metaoperator
pmichaud "so easy, even a caveman can do it." 20:38
colomon pmichaud: seriously, it's just (@a Z @b).map(-> $a, $b { $a + $b; }), isn't it? 20:40
the only tricky bit is handily the grammar to make using it elegant.
*handling
pmichaud colomon: yes, that works 20:41
or even { $^a + $^b } for @a Z @b
TimToady of course, Z could in some cases hyperize itself too 20:43
colomon TimToady: S»op« -- example says "single-thread", but does it also implement "serial" (ie in order)
TimToady "serial" is one of the things the S stands for
colomon ?
TimToady: is that a yes? 20:44
PerlJam colomon: See S03:4282 :-) 20:46
colomon PerlJam: That's exactly where I'm looking. 20:47
PerlJam colomon: I know ... the paragraph right above the example you gave seems pretty clear to me. 20:47
colomon PerlJam: combined with the examples it doesn't seem that clear to me. 20:51
PerlJam colomon: why? Do you think it's doing something different in each of those examples? 20:52
colomon In particular, normal hyper-ops both don't have a default ordering and are potentially multi-threaded. 20:53
The example suggests S makes a hyper-op single-threaded.
That doesn't tell me if it is also serial. 20:54
It certainly isn't short-circuit, I hope!
I'm trying to figure out what set of S-words apply.
And are they still otherwise hyper? 20:55
It seems like serial, single-threaded hyper-ops could be lazy. This spec most definitely does not say that, though...
colomon Though I suppose the only point (that I can see) to force single-threading is to also force it to run in order. 21:07
spinclad well, it does say Sequential...
ash_ forcing single-threading might also be to protect the data if you don't know if its thread safe? 21:20
colomon ash_++ 21:24
ash_ since most people don't write threadsafe code by default, since its only occasionally a legitimate concern 21:25
ash_ completely unrelated to perl 6 but i found this, its pretty cool, this guy visualized some sorting algorithms, corte.si/posts/code/sortvis-fruitsa...index.html 22:18
ash_ is there a reason for ng1 on github? 22:24
pmichaud ng1 is where I'm going to push my list/iterator changes for the next couple of days 22:27
because they're guaranteed to break tests for a short while 22:28
when it's done (hopefully tonight/tomorrow), I'll merge back to ng
ash_ is it that big of a deal if ng regresses? since its not master 22:29
pmichaud no, but branches are cheap. 22:32
and merges are easy in git.
ash_ yeah, true
pmichaud I only expect to keep the branch for a day or so, unless I bog down, in which case it's much easier to throw away the branch than it is to revert a bunch of changes
and that's the other reason for using a branch, I'm not sure that the next attempt will be the one we ultimately want to keep 22:33
although I already ripped out the Parcel -> List conversions in ng1, and I'm surprised at how much still works :)
although arrays are pretty much hosed atm
ash_ do any of the perl 6 list things have much of an affect on nqp-rx? 22:37
pmichaud not yet. the @(...) definition might.
but it should be pretty similar overall. 22:38
the main reason nqp-rx doesn't have an issue is that its lists aren't lazy :)
and there's no flattening or list context -- it's just binding
ash_ ah, okay, cool 22:40
PerlJam nqp-rx++ (A verful useful version of simplicity) 22:46
s/verful/very/ 22:47
pmichaud hmmm
PerlJam one of these days I'll get my fingers and brain a little more coordinated
japhb Still, the sentiment was accurate. 22:48
pmichaud looks like the difference between .list and .iterator is that the former is marked as "flattening" 22:50
s/is/might be/
ash_ i am doing an independent study with a professor on compilers soon, i was thinking of trying to implement part of nqp for part of it
pmichaud ash: that'd be cool
pmichaud need walk -- bbl 22:52
ash_ i am working from the Compilers principles, techniques and tools second edition and the crafting compilers book, so i'll see what happens
davidfetter oh hai 22:54
PerlJam ash_: what would your compiler generate? C? or something else?
davidfetter what's the latest re: rakudo atop parrot 2.0?
ash_ probably llvm for now, i don't know though, i am still learning :P 22:55
PerlJam ash_: were you going to try the GSoC too? I think I saw you say something about that on #parrot 22:56
ash_ yeah, this independent study is only till may-ish, so GSoC i think is more summer time, i was hoping to learn about compilers in general and then hoping for the GSoC to do the stack frame builder in llvm if it hasn't been done, or some other things if i can figure out something useful to try with parrot 22:58
the independent study is so i am not completely lost if i talk to the #parrot people about compilers 22:59
pmichaud davidfetter: rakudo runs on parrot 2.0 23:10
(both ng and master branches)
ash_ unfortunately there hasn't been enough interest in a compiler class at my college, so i am doing it as an independent study 23:13
lichtkind why is parrot no 2.0 23:16
API breakes?
Tene lichtkind: what? why is parrot 2.0? Because January happened.
lichtkind ah so year was over 23:17
i thought parrot 1.0 was because to st an API that will not be changed until 2.0
ash_ the major number changes once a year, its 2.0 this year, next year it will bump to 3.0 23:18
for parrot
davidfetter pmichaud, great! is there anything else gating distribution on fedora?
ash_ i only know because i asked them a few days ago :P
lichtkind ash_: so no major API breaks? 23:19
ash_ nope
well, Context and CallSignature PMCs merged into CallContext but thats all in the changelogs
i think thats the biggest change incompatibility change i can think of, but ask on #parrot for more details 23:20
lichtkind ash_: thanks but i was never much into the low level side 23:21
hudnix rakudo: class A { method foo {say "foo"} }; class B {has A $.aaa handles 'foo' }; my B $b; $b.foo 23:54
p6eval rakudo 1d4928: ( no output )

Powered by Cro and the Raku® Programming Language.

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

Thank you!