»ö« | 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.
pugs_svn r29599 | lwall++ | [S07] start to work out relationship of item/slice context 00:00
r29599 | (seems they treat parcels similarly, if not identically...)
TimToady (also doc EMPTY exceptions) 00:01
00:01 uniejo joined
pmichaud TimToady: Iterable flattens in list context... how about Iterator? 00:02
(an iterator in a scalar doesn't flatten, but a "bare" iterator...?)
right now I'm working on the assumption that they do flatten -- makes a few things impler 00:03
*simpler
00:05 nihiliad left
colomon pmichaud: when I try to feed a Range or a RangeIterator to .map, it dings me about missing method list... 00:06
pmichaud yes, known issue
00:06 quietfanatic left
pmichaud I have to get .list added in a variety of places 00:06
00:06 lumi left, lumi joined, mikehh left
pmichaud actually, try this: in class Iterable, add 00:06
method list() { self.iterator } 00:07
00:07 mikehh joined
pmichaud might work. 00:07
colomon wondered if it might be that simple.
pmichaud that will probably break at some point -- .iterator may need to return a scalar
but worth trying for the moment
pugs_svn r29600 | lwall++ | [S03] add new E operator
pmichaud (fwiw, I agree that the huffmanization feels wrong on "E") 00:08
colomon er, I'd need to create a Iterable.pm to do that, right?
pmichaud colomon: yes, probably
colomon I'm being beat on by a small child, will try that just in Range for the moment for simplicity.
TimToady it's huffmanized by capitalization :) 00:09
vertical huffman coding...
pmichaud even then it feels too short :-)
but IANALD
TimToady it's also potentially a metaop
like Z might be someday, if we do zipwith as Z+ 00:10
colomon is now picturing TimToady working font size into the mix, so that taller than normal E is the operator.
TimToady decommuting &
colomon your suggested .list works seems to work for Range. 00:11
Actually, seem to be getting a moment of respite from the boy, I'll try adding Iterable.pm here.
pmichaud might be worth waiting on that 00:12
colomon er?
pmichaud I need to think about .list a bit more
colomon okay, can do that too.
or rather, I can easily do nothing. :)
So, if you feed an iterator to .perl, should it iterate and output the list of results? 00:13
00:13 mikehh left 00:14 mikehh joined
colomon if nothing else, that would make testing map a lot easier at the moment... 00:14
00:16 synth joined
pmichaud you can do .eager.perl for the moment 00:17
colomon \o/ 00:18
(1..5).map({$_*$_}).eager.perl.say
(1,4,9,16,25)
00:18 cdarroch left
lichtkind TimToady: how does relate viv to gimme5 ? 00:19
pmichaud laziness at work: 00:21
> my $a = (1,4,6).map({ say $_ * $_; }).iterator; $a.get; say 'wait'; $a.get;
1
wait
16
00:22 _ash joined
pmichaud if we have: my $a = (1,4,6).map({ say $_ * $_; }); 00:23
what should $a contain? A Seq? 00:24
(I'm guessing yes.)
00:25 dkulchenko joined
pmichaud afk, fetching dinner 00:27
colomon pmichaud: wouldn't it be the same type of thing $a contained if you said my $a = (1, 4, 6) ? 00:28
00:29 dkulchenko left
colomon afk, time to put someone to bed 00:29
00:40 uniejo left, athaba left
_ash would it try to make the list into item context? which means a capture? 00:42
.map i would expect to return a list, and since $ is item context i'd expect it to return the list in item context, so a capture 00:43
00:44 lichtkind_ joined
_ash S03 has: item map { $_, $_*2 }, ^4 # [\(0,0),\(1,2),\(2,4),\(3,6)] 00:46
i'd personally expect something similar, but i have been wrong many times before 00:47
although, i just noticed your using say in yours... would that be a list containing True, True, True then? 00:49
rakudo: say (say 'hi').WHAT; 00:50
p6eval rakudo 1d4928: OUTPUT«hi␤Bool()␤»
00:51 Chillance left, dduncan joined
_ash also, i could not be taking lazyness into account, so... maybe its supposed to be an iterator or Seq if its lazy 00:52
00:52 Chillance joined 00:56 lumi left, lumi joined 01:01 lichtkind left
dduncan TimToady, about a recent synopsis change about Seq that I commented on, do you consider that any type which is lazy must also be classified mutable? 01:03
I refer to r29582 and a Jan 23 comment 01:04
01:06 quietfanatic joined
dduncan on p6l 01:06
01:09 meppl left 01:19 araujo left
pmichaud dduncan: immutable types are allowed to do lazy evaluation 01:21
dduncan so why was Seq declared mutable then? laziness seemed the cited reason, which I disagree with
see www.nntp.perl.org/group/perl.perl6....33123.html for what I said before ... never got an answer 01:22
01:22 jferrero left
lichtkind_ good nicht 01:22
night 01:23
01:23 lichtkind_ left
dduncan pmichaud 01:24
pmichaud ah, I see. I didn't notice Seq being declared mutable. That surprises me a little also, but not enough to worry about it at the moment. 01:27
01:27 pmurias left
dduncan that concerned me though 01:29
I have a stronger interest in the parts of the language about data types
pmichaud oh. Seq is listed as immutable also 01:35
01:35 drbean joined
dduncan hmm ... 01:35
pmichaud I suspect it's a typo
dduncan so it is 01:37
but r29582 definitely *added* it to Mutable
and I thought things were only supposed to be in 1 category
if Mutable and Immutable aren't mutually exclusive, that needs explaining 01:38
pmichaud at the time of the change we were still (and still are) trying to work out the details of the iterator interface
so Seq in that context was (I suspect) intended to replace the previous notion we had of List 01:39
while also recognizing that lists (as iterators) are in fact mutable
dduncan I can understand that respect, if some iteration on a Seq would change the results of some other iteration
but then it seems better to have 2 separate types, eg a Seq and an Iterator ... and maybe you do 01:40
but the docs need cleanup
pmichaud I suspect the mutable version will get a different name
dduncan perhaps SeqIterator?
pmichaud at the momnt, the ng1 branch is using List and Iterator 01:41
dduncan speaking of Rakudo, I notice the front page didn't announce last week's release 25
01:41 renormalist|work left
pmichaud yeah, I got sidetracked and then didn't post the announcement 01:42
need to do that now
dduncan I guess there's no automatic note when downloads is updated then
like with CPAN feeds
pmichaud at the moment, no
pmichaud tries "make spectest" in ng1, just to see the fireworks :) 01:45
01:46 renormalist|work joined
_ash fireworks are cool at times 01:46
01:46 LaVolta joined
dduncan so is ng trunk now, or just planned to be before 26 comes out? 01:49
pmichaud planned to be before 26
dduncan okay
01:54 lumi left 01:55 lumi joined 02:01 jaldhar joined
_ash so, should $a = map { $_ * 2 }, (1, 2); return a Seq? 02:02
dduncan I would think so 02:06
is it better for $a to be an Array instead?
in the general case I would say no
never mind, presumably you'd use [1,2] if you want the Array 02:07
unless I'm confused 02:08
I think of [...] building an array and I don't know the literal syntax for building a Seq, so I've been saying Seq.new(...) so far
_ash well, i'd think the map would return a list, and since its an assignment to an item, it should call item context on the list
dduncan I thought List was recently eliminated, but maybe it was just changed 02:09
_ash list? as in ( ) lists? 02:10
dduncan I meant the type called List ... looking ...
pmichaud it was aliminated, yes 02:11
*eliminated
but it may be coming back
_ash when did that happen? wow, i missed that apparently
dduncan I see List is a role, but not a class 02:12
pmichaud my point is that it's not set-in-stone as to *what* it is 02:13
it's a "best guess" after considering the issues that were brought up late last week
_ash ah, i see, i guess i am thinking in the wrong terms then of what types of things are being passed around 02:14
dduncan all I know is that, for each of the simple collection types, like sets, bags, sequences/arrays, mappings/hashes, I want some type that is a "value" type ... as far as I know we do, but if Seq was made mutable it seemed then we didn't 02:15
hmm, I am reminded or it looks like Enum and EnumMap are what used to be called Pair and Mapping, which were immutable 02:17
02:17 ShaneC left
TimToady I'm fine with Seq being considered immutable (but lazy), and adding a SeqIterator or whatever 02:18
can't do it myself at the moment, have to go out tonight. 02:19
bbl &
dduncan thank you
pmichaud ng1 has SeqIterator :-) 02:20
02:21 nihiliad joined
dduncan I'm going to copy that note to p6l before it is forgotten ... 02:21
in reply to the commit note that started it 02:22
02:26 ndeuwrrr joined
huf YES. FUN. 02:27
02:27 Guest52934 left 02:29 Chazz joined, Chazz is now known as Guest71329, Guest71329 left, Patterner left
dduncan okay, done 02:32
02:32 Chazz_ joined 02:34 quietfanatic left 02:36 orafu left, orafu joined 02:37 werdan7 joined, dduncan left
diakopter ugh 02:38
02:39 diakopter sets mode: +R 02:40 ndeuwrrr was kicked by diakopter (diakopter)) 02:42 lumi left 02:43 lumi joined 02:46 diakopter sets mode: -R 02:47 sbilik joined, hercynium joined 02:50 nothingmuch left, Exodist left, wolverian left, aesop left, breinbaas left, nothingmuch_ joined, aesop joined, breinbaas joined, jaldhar left 02:51 wolverian joined, breinbaas left, Exodist joined 02:53 mikehh left, breinbaas joined 03:00 mikehh joined 03:01 diakopter sets mode: -R 03:02 Baggiokwok joined 03:04 Baggiokwok left 03:05 pilif12p joined, pilif12p left 03:06 mikehh left
colomon > (1..100).map({ $^a % 5 == 1 ?? $^a !! Nil}).eager.perl.say 03:06
((),(),6,(),(),(),(),16,(),(),(),(),26,(),(),(),(),36,(),(),(),(),46,(),(),(),(),56,(),(),(),(),66,(),(),(),(),76,(),(),(),(),86,(),(),(),(),96,(),())
That's with Iterable.list { self.iterator; }.
03:06 mikehh joined, am0c joined
PerlJam colomon: is .eager doing anything useful there? 03:07
colomon Yes, it's needed to get .map to iterate.
PerlJam hmm
03:07 RichiH left
colomon It's not a long term thing, it's a today thing. 03:08
03:10 nihiliad left, RichiH joined
colomon what I'm trying to figure out is where half of the numbers went. 03:10
03:10 tmodiabcpd joined, tmodiabcpd left
colomon > (1..100).list.eager.elems.say 03:12
100
> (1..100).map({ $^a % 5 == 1 ?? $^a !! Nil}).eager.elems.say
10
03:13 mikehh left
pmichaud Nil is an empty parcel 03:13
but yes, some numbers are missing 03:14
colomon right, should be 20.
PerlJam ng: say 11 % 5
p6eval ng 22b55c: OUTPUT«1␤»
pmichaud > say { $^a , $^a }.count
2
colomon and if you look back at the .perl output, half of the numbers that should be there are missing, and at least of of the Nils.
ooooo.
pmichaud it thinks the block has two parameters.
ng likely has the same problem 03:15
ng: say { $^a, $^a }.count
p6eval ng 22b55c: OUTPUT«2␤»
03:15 mikehh joined
colomon Hey, so it's a minor block problem and not a map issue at all. \o/ 03:15
pmichaud adds to ng's todo list
03:15 araujo joined
PerlJam colomon: at least it's not the iterator :) 03:15
pmichaud just pushed more changes to ng1 03:16
this gets Array and Seq working more properly
colomon pmichaud: so for very very small values of "I ran some tests", Iterable.list { self.iterator; } works okay. 03:17
pmichaud oh, I just change Iterable.list to return self :-)
*changed
colomon hmmmm....
and did it in PIR, I see. :) 03:18
PerlJam just noticed that there doesn't appear to be any tags for the Dec release 03:19
colomon pmichaud: why can Array's !STORE just go away like that?
pmichaud it inherits from Seq 03:20
colomon ah.
pmichaud Array used to inherit from List, and a bit difference between Array and List was that Array had copies of values which List had the original sources 03:21
*big
but now Array inherits from Seq, and Seq has copies of values also
I'm still trying to work out the exact meanings of List, Iterator, .list, and .iterator 03:22
colomon understood.
pmichaud my gut feeling is that List is an iterator that supplies flattening list context
colomon still feels like you are making a lot of progress.
03:22 am0c left
pmichaud yes, I am 03:22
once we get to the point of being able to run tests through ng1, it becomes much easier to say "oh, this can't be right -- have to fix" 03:23
03:23 mikehh left, RichiH left, RichiH joined 03:25 mikehh joined
colomon Seems like the spectest is already doing a lot better than it was two days ago. 03:26
(not that I counted, but tests seemed really broken the other day.) 03:27
03:30 mikehh left, lumi left 03:31 lumi joined 03:32 mikehh joined
colomon I take it gather / take is still broken? 03:32
03:33 Chazz_ left
colomon oh, wow. I almost feel like I can see how to turn it into an iterator. 03:36
03:37 mikehh left 03:38 mikehh joined, sbilik left
colomon hmmm... do you have to set the exception handler each time in .get, then? 03:39
pmichaud yes, gather/take still broken 03:44
colomon I feel like I can almost see what it should be, but not quite.
03:45 diakopter sets mode: +R
colomon ah well, should go to bed. 03:48
03:48 samlh joined
colomon I'll be very interested to see how gather / take ends up being implemented. 03:48
03:50 samlh left 03:55 LaVolta left 03:56 lumi left, lumi joined 04:03 Chillance left 04:07 stepnem left 04:14 stepnem joined 04:23 jaldhar joined 04:27 jaldhar left 04:28 jaldhar joined 04:31 justatheory left 04:35 LaVolta joined 04:39 jaldhar left, jaldhar joined 04:44 lumi left, lumi joined 04:50 jaldhar left, jaldhar joined 05:02 quietfanatic joined 05:04 pnate2 left, pnate joined 05:08 dilip joined, ycxwgzzvmz joined, ycxwgzzvmz left 05:09 dilip left
Tene g/t is broken in ng1? 05:10
05:13 stephenlb left 05:22 diakopter sets mode: -R 05:43 lisppaste3 left
Tene Okay, if I understand what the current model is, and I probably don't, this should work perfectly. :) 05:44
pmichaud looks for a diff 05:48
05:51 lisppaste3 joined
pmichaud just fixed Array.push|pop|shift|unshift 05:52
05:54 lumi left, lumi joined
Tene I haven't posted it anywhere yet. I'm testing before I commit. 05:54
It, um... kinda works. >.> 05:55
i wonder if I could implement a non-lazy version first, instead... 05:56
pmichaud lazy one should be easier, actually.
Tene The saved continuation ends up returning to the wrong place, is the problem. 05:57
pmichaud nopaste? 05:58
Tene see #parrot 05:59
05:59 _jaldhar joined 06:11 logre joined, logre left 06:17 pnate2 joined 06:24 jaldhar left, c9s left 06:25 c9s__ is now known as c9s 06:27 _ash left, fda314925 joined 06:31 pnate left
TimToady pmichaud: I don't see how a List type can work. Each iterator has to decide parameter by parameter how it's bound and whether it's flattening; a sig intermixes those demands. 06:40
hence the new methods in S07, get is flattening, but getitem is not.
getitem returns the next parcel, which is what you want either for positional parameters or slice elements 06:41
(assuming non-parcels to be degenerate parcels)
slice parcels are different from positionals primarily by coming in the variadic region. 06:42
but I think they're more or less the same from the iterator's perspective. 06:43
(method names are negotiable, of course)
pmichaud TimToady: I see List as an iterator that flattens a-la list context 06:44
while other iterators simply return parcels according to their natural way of doing things 06:45
so, for list context, we simply wrap another iterator in a List
and it handles flattening
and .get is always like ".getitem"
i.e., an iterator author always implements .get, which returns parcels 06:46
TimToady argument lists *switch* to list context partway through
based on slurpy demands
pmichaud right. so when the parcel is being bound to a signature, it can send the slurpy arguments to a List iterator 06:48
which then imposes the list context on the remaining arguments
TimToady okay, maybe. seems like an extra iterator, if the context knows which method to call 06:49
but I can see how that could be made to work, assuming we never switch back to itemizing parcels 06:50
pmichaud well, I can see how the other can work as well.
would you see .getitem as being the more fundamental, and the Iterator type then provides a default .get ?
(that knows how to flatten based on .getitem?)
TimToady it also bothers me in the context of nextsame a bit
pmichaud I haven't read the S07 update yet
TimToady since the subsig might have a different idea, and the Capture might switch prematurely to list iteration from the standpoint of the subcall 06:51
pmichaud I'd hate to see every iterator type have to implement its own list flattening code
well, in the version I'm doing, the parcel itself remains immutable, so it could be rebound
06:52 pnate2 left, sjohnson sets mode: +r
TimToady 'kay 06:52
sjohnson diakopter: putting +R isn't going to stop version requests, because they are CTCP'd to the channel, and he is not talking. +r will prevent them from joining in the first place
pmichaud ...but I'm real fuzzy on nextsame semantics, and don't have a strong horse in the race, so I'd prefer to go with your guidance
the other advantage of a List iterator is that Seq and Array (very common) can optimize based on knowledge of List's internal structure 06:53
TimToady it just seems to me we probably shouldn't commit to flattening more than one parcel at a time, in case we get fancier with signatures that can intermix listy/slicey things someday
though certainly there are some lists we can know will stay lists at compile time 06:54
pmichaud oh, in early versions of ng1, I actually was envisioning that Parcel could have its own iterator
or, we could have an iterator that knows what to do in signature binding contexts
or still further, List could be smart enough to provide .get and .getparcel semantics :-) 06:55
so, .get flattens, and .getparcel (or .getitem) gets the next item
TimToady if all iterators support pushback, then parcel flattening can simply be pulling the parcels contents up into the not-gotten-yet list and then looking at the front again 06:56
pmichaud I'm not sure all iterators should support pushback, though.
I'm fine if they do, though. In which case I think it should just be standard in the Iterator type
TimToady I'm not sure they shoudn't... 06:57
pmichaud I'm trying to make sure that individual iterator authors don't end up having to rewrite pushback code :-)
TimToady anyway, with that approach, you never have to commit to flattening more than one (top-level) parcel at a time
pmichaud hmmm... as it is now I'm not really committed to flattening more than one parcel 06:58
TimToady and one could conceivably have sigs that alternated flattening bindings with non-flattening, somehow
pmichaud it just seems a little expensive to have every iterator support a pushback queue
TimToady well, substituting an iterator for one parcel is isomorphic to hoisting it into the todo
pmichaud and .get/.getitem have to know to read the pushback 06:59
TimToady well, maybe they don't have to, if pushback is just substituting a different iterator whose tail continues with the original iterator 07:00
pmichaud right, that's where I was heading with List
TimToady I don't like to call that List, I guess 07:01
pmichaud well, here's what I'd like to see (more)
someone implementing an Iterator really only needs to write a .get method that returns a parcel representing the next item in the iteration
(I'm fine if it's called .getitem) 07:02
the other behaviors should probably be built in terms of that particular method
and the person writing .get shouldn't have to worry about pushback, or handling pushback should be extremely straightforward
TimToady maybe just use .get from parent class/role 07:03
if it can do the wrapper iterator to schedule todo
or to do pushback
pmichaud I was working from the idea that Iterator itself would be lightweight, and the pushback and other behaviors would come from other special-purpose Iterators 07:04
(or one super-iterator that could provide a combination of those methods)
....more to the point, let me ask a few questions that might clarify things in my head
TimToady as usual, I'd like to have my cake and eat it too :)
pmichaud what, exactly does .list return?
for example, if I have @a.list --- what am I getting back? 07:05
07:05 PacoLinux left
pmichaud I've been thinking it would be the elements of @a in list context 07:05
TimToady that seems like a no-op to me, if @ already implies .list
pmichaud (which, don't flatten, obviously)
it can be a no-op, yes.
now then ,what about something like @foo.map({...}).list ? 07:06
TimToady depends on the signature of the block
pmichaud okay, so .list doesn't mean "list context" here? 07:07
TimToady map/grep signatures are like the repeating groups in a variadic section of a signature
pmichaud I would think that .list would imply flattening behavior
TimToady it would throw away the parcels returned by each map, at least
pmichaud right
TimToady flatten, rather
pmichaud which is actually somewhat different from a plain @foo.map({...}) 07:08
TimToady yes, that doesn't commit its result to flattening
07:08 diakopter sets mode: -rR
pmichaud so, whatever is returned by @foo.map and @foo.map.list has to be "different" somehow 07:08
TimToady a .list contains no parcels 07:09
pmichaud right
but both are lazy
and both are effectively iterators
which means there's something different between the two
TimToady depends on whether the person reading it use .get or .getitem
*uses
pmichaud I would think that .get on the thing returned by .list would always be flattening 07:10
TimToady well, no differnce in the list case
pmichaud and .getitem as well
TimToady since the parcels are gone
pmichaud right
TimToady .get is always flattening, but .list never gives it any parcels to flatten
pmichaud the parcels are gone in the .list case, which means it's transforming the result, which means it's another iterator of sorts
okay, then I'm thinking more of .getitem
TimToady which is what binding to a positional or a slice does 07:11
pmichaud right
TimToady and I'd like the sig of map/grep to be able to indicate which method to call
default is .get, since we're assuming flattening
but we need a way to indicate a parameter that is a "slice" element 07:12
it's like map and grep sigs are really subsigs of a larger repeating variadic sig
pmichaud by "sig of map/grep", do you mean the sig of the block?
Khisanth sjohnson: actually the +R does stop the CTCPs
TimToady currently -> $x {...} treats $x as positional, but map really wants that to use .get, not .getitem 07:13
Khisanth it gets you a ":Please register with services ..." reply from the server
TimToady yes, the sig of the block is really implicitly slurpy in a way
and goes with the business of returning a partial match cursor in the iterator 07:14
diakopter Khisanth: yes, another problem is that they're actually registered
sometimes
TimToady if you pass a parcel to a normal positional, it binds as a single item
diakopter it's just less than a day until they switch ircds
TimToady that is not your indicate expectation for map's $x
*indicated
you expected (1,2,3 Z 4,5,6).map to flatten 07:15
pmichaud I wasn't sure what to expect, actually :-)
TimToady so we need some way of marking such a sig as implicitly variadic
pmichaud thus the question posed in Pm-19 :-)
TimToady yes, which I've been mulling very hard. :) 07:16
and realizing that map/grep signatures aren't the same beasts as normal sigs
but more like a *$x *$x *$x ... in a normal sig 07:17
pmichaud right
TimToady except called repeatedly
so we don't have to worry about the fact that $x means different things
pmichaud I see how it affects the map/grep signature now
interesting.
TimToady so it's a bit like subrule matching
pmichaud indeed. 07:18
TimToady which works differently from matching a complete regex
it's anchored to a position, and implicitly quantified externally, and returns its final position for the cursor
pmichaud okay, so let me ask a few questions
07:19 mberends joined
diakopter mberends: hi 07:19
pmichaud every iterator would support .get and .getitem ?
mberends good (evening|morning)
07:19 diakopter sets mode: +o mberends
TimToady in my current view, yes, though derived support is fine 07:19
pmichaud people writing iterators would tend to write .getitem, and the Iterator could derive .get from that? 07:20
TimToady yes, where getitem returns the actual next object, even if it's a parcel
pmichaud right 07:21
TimToady what you'd bind a positional to, normally
pmichaud .list produces something that maps .getitem to .get for the underlying iteration?
TimToady yes, they become identical, presumably
pmichaud (so that .getitem on a .list result ends up providing the flattening semantic)
TimToady yes, the parcel boundaries have disappeared 07:22
pmichaud well, they disappear lazily, yes?
TimToady sure
pmichaud as opposed to all-at-once ?
okay
I tend to think of List() as being an Iterator that just maps .getitem to .get, then :-) 07:23
(and has an underlying iterator it reads from)
I'm fine if we call it something else, or eliminate "List()" entirely in favor of a flag on an Iterator that says "you always flatten"
TimToady could naturally, though perhaps not efficiently, be done with gather/take on the underlying
pmichaud yeah, I tend to think of it in terms of having a pushback structure :-) 07:24
TimToady I am leary of flags that have to be introspected these days :)
pmichaud at least from an efficiency perspective
right, so if it's not a flag, it seems like it wants to be its own type 07:25
diakopter bleary
pmichaud I liked "List" because of the analogy to "list context" and "result from .list"
TimToady it would seem that pushback should fall out naturally somehow, though if you want to push back a parcel, and the outer is assuming list, you could have a problem
07:26 nnyoyit joined
pmichaud I suspect pushback does fall out naturally 07:26
diakopter ok, expect severe oddities from irc; freenode is switching ircds now
07:26 nnyoyit left
pmichaud oh, wait, it doesn't quite fall out naturally. drat. 07:27
can we have a way for iterators to support pushback such that the person writing .getitem doesn't have to worry about it? 07:28
TimToady as long as getitem can tell its caller that its iterator has mutated to one that supports pushback somehow
pmichaud I feel like I'd like to have (module names) ".gennext" which lazily produces the next item in the sequence, while ".get" and ".getitem" check the pushback queue first before calling .gennext 07:29
Tene pmichaud: gather/take pushed
TimToady which kinda argues that they all should, so you don't have to have that as a requirement
pmichaud i.e., I'd like to separate the "read from iterator" methods from the "generate the next element" method
TimToady that might be useful
well iterators are mutating anyway, so switch implementations on the fly could be okayish 07:30
pmichaud so, the Iterator base type provides the standard API for reading from an Iterator, and specific iterator implementations focus primarily on the "here's how you produce the next element" method
TimToady *switching
with perhaps a hot-track for unpushed, non flattening iterators 07:31
but that's an optimizaiton
pmichaud sure
and checking the pushback queue isn't likely to be all that expensive anyway
TimToady well, if it's good enough for getc :) 07:32
pmichaud it can be an internal optimization flag
TimToady switch vtables, and all that
pmichaud right
actually, the "read from iterator" method just points to the "generate the next element" method for unpushed, non-flattening :-) 07:33
er, read item from iterator
but I think they should have different names
(and if you agree somewhat... what names would you like? ;-) 07:34
Tene++ 07:35
TimToady maybe produce and producesome 07:36
and I'm still officially worried about serial assumptions :) 07:37
pmichaud good point :)
diakopter more worried about cereal consumption
pmichaud s/next//
TimToady anyway, "gen" is too close to "get" visually 07:39
pmichaud agreed
TimToady and as private-ish methods they want dehuffmanization
pmichaud 'generate'
diakopter .pull 07:40
TimToady wonder how 'hyper' gets passed in
pmichaud i've been wondering if hyper is just another form of iterator :-)
but likely no 07:41
TimToady it seems to influence 'generate' more than 'getitem'
pmichaud yes
TimToady it's the generate that wants to distribute
pmichaud exactly
well, there's always .generate(n)
but that feels like maybe it should be .hyper(n), which then calls generate...... 07:42
TimToady that's .generatesome(n)
well, that's for another day, I expect 07:43
which isn't for another 17 minutes here
pmichaud that'd be fine with me. is .generate okay for now, or do you think you'll want something different?
and did you ever decide on a replacement for IterDone ? ;-)
(no, I didn't read the diffs today ... pmichaud--)
TimToady currently specced as EMTPY
pmichaud okay
TimToady only spelled right
pmichaud and .generate ... ? 07:44
TimToady is fine for now
pmichaud okay
we'll go with that
and every iterator has .get and .getitem methods
and perhaps the ability to pushback built-in
TimToady I have to think about map sigs more, but that just shows up in to the iterator in which of those two are called
my engrish is rotting 07:45
still planning the demise of @@ in there as well, somehow 07:46
pmichaud okay, thanks for those decisions. We'll rework the ng1 branch to match.
TimToady thanks for you patients
*your 07:47
pmichaud the other fixes we've done already to iterator code has really shortened some of the methods, too
and made the execution a fair bit more optimal
diakopter patients are either victims or hypochondriacs
pmichaud so I'm very happy overall with progress this week, although it's been far slower than I had hoped
TimToady the two are not mutually exclusive
pmichaud but I think we'll be back on track real soon
TimToady well, my sole criterion is whether it's converging, not how fast 07:48
pmichaud yes, but I have a target date :)
TimToady *I* didn't promise anything in April :)
pmichaud no, you didn't. :)
diakopter it was in the stars...
pmichaud well, when Rakudo * releases in April, and people say "but it doesn't match the spec", I can just say "Whatever!"
TimToady well, ** might indicate slurpy slice 07:49
07:49 brrant left
pmichaud snickers.... we're back to the steamroller again, but now it means *don't* flatten! 07:49
TimToady really ought mean hyperflatten
diakopter ***
TimToady *oughta
gha gotta goto bde sonn 07:50
diakopter std: ***int
p6eval std 29600: OUTPUT«ok 00:01 105m␤»
pmichaud yeah, same here. oh wait, I'm already in my bed! :-)
TimToady well, |$x is availabe, and maybe ($x)
nighty night
pmichaud ($x) looks good from a parcel perspective
TimToady yeah, if it doesn't interfer with what we have already there in sigs 07:51
zzz & # thunk
pmichaud sleepytime here also -- bbiaw 07:52
07:54 lumi left, lumi joined, eternaleye left
diakopter hopefully soon we'll have a new freenode. 07:55
std: ****** 07:56
p6eval std 29600: OUTPUT«ok 00:01 105m␤»
07:58 jql left, jql joined
diakopter std: ***pi***^^***$!&&***@$() 08:00
p6eval std 29600: OUTPUT«ok 00:01 107m␤»
08:00 LaVolta left
quietfanatic language, diakopter. 08:00
diakopter or something
mberends it parsed!
diakopter pugs: ***pi***^^***$!&&***@$() 08:01
p6eval pugs: OUTPUT«*** ␤ Unexpected "***"␤ expecting program␤ at /tmp/siVy27Zbz2 line 1, column 1␤»
diakopter program! posh.
rakudo: ***pi***^^***$!&&***@$()
p6eval rakudo 1d4928: OUTPUT«** (HyperWhatever) is not yet implemented at line 10, near "*pi***^^**"␤in Main (file src/gen_setting.pm, line 2582)␤» 08:02
quietfanatic I think by current grammar rules, any number of stars can go between two terms or two operators, and any number larger than one can go between a term and an operator.
diakopter rakudo: ordinate
p6eval rakudo 1d4928: OUTPUT«Could not find non-existent sub ordinate␤in Main (file src/gen_setting.pm, line 324)␤»
quietfanatic Some things don't change :)
diakopter std: 3***3 08:03
p6eval std 29600: OUTPUT«===SORRY!===␤Two terms in a row at /tmp/we9CJhatgj line 1:␤------> 3***⏏3␤ expecting any of:␤ POST␤ bracketed infix␤ infix or meta-infix␤ postfix␤ postfix_prefix_meta_operator␤ statement modifier loop␤FAILED 00:01
..106m␤»
quietfanatic Huh
Oughtn't that be 3 * * * 3? 08:04
diakopter ltm
3 ** * 3
quietfanatic Oooooh
right
diakopter well, 3 ** * fail
quietfanatic At least until someone writes prefix:<*> 08:05
diakopter nytol& 08:06
colomon routinely has dreams where he is back at college but has forgotten to go to class all semester. This is the first time even he has had a dream where it is the first day back at college for software engineering, and the college has sold its soul to Microsoft, which has representatives crawling all over the campus trying to convince all the new students to sell their souls... 08:10
backlogging. 08:11
08:12 cjk101010 joined
mberends wants to buy back his soul, paying in #perl6 tuits... 08:12
08:19 drbean left, yves left
cj any of you lingrists want to learn something about Lushootseed? 08:20
wp.colliertech.org/cj/?p=714
colomon Tene++ # gather / take 08:23
Though, um... 08:24
> my $a = (1..10).grep({$^a % 3 == 1}); my $b = (1..10).grep({$^a % 4 == 2}); say $a.get; say $b.get; say $a.get; say $b.get;
2
6
08:31 wanradt joined
colomon Current code only allows us to have one gather / take active at a time? except that isn't quite right, it's like two copies of the same gather / take instead of two different ones. very odd. 08:32
12:52 ilogger2 joined 12:54 mssmfs joined 12:55 tomaw joined 13:02 arnsholt joined 13:03 sunnavy joined
colomon Tene: ping? 13:07
phenny: ping? 13:20
13:22 dakkar joined
colomon hello world? 13:27
Su-Shee "yes, my son?" 13:28
colomon oh good, I'm not the only living person on #perl6
Su-Shee no, it's just heavily splitted it seems.
colomon ah, I thought whatever was happening last night was supposed to fix that. 13:29
Su-Shee maybe a deep sea internet cable again ;)
colomon well, we're on opposite sides of the Atlantic... :) 13:30
jnthn I think the ircd migration last night might have caused everyone to fall off the channel.
Su-Shee jnthn: and they plainly didn't rejoin?
hm, good opportunity to clean up :)
jnthn Su-Shee: My client normally manages to re-join automatically
Su-Shee: But failed to for some reason.
colomon jnthn: same here.
jnthn Suspect it was just a side-effect of the migration then. 13:31
colomon jnthn: do we have a spot for rakudo-specific test files?
jnthn colomon: Rakudo-specific?
colomon: t/ in the Rakudo repo is perhaps the place though.
colomon for instance, we've got MapIterator now, which is a pretty key component, but it's not in the spec, as far as I know. 13:33
saschi hi
colomon hello 13:34
13:38 buu joined 13:43 LylePerl joined
LylePerl hi all 13:44
Following the success of our groups Perl talk at University of Western England, Bristol 13:45
13:45 buubot joined, lisppaste3 joined
LylePerl I've convinced them to host what we are calling "Perl 6 Discovery Workshop" 13:45
Details at www.perl6.org.uk 13:46
colomon ah, the source of the mysterious web page. :)
LylePerl :)
Yeah, got bogged down with uni work, etc, so this has got a little delayed 13:47
was planned for next month, but probably wont be until march april now
jnthn LylePerl: Where abouts in the UK will it be, out of curiosity? 13:48
Oh, wait, Bristol.
jnthn should read
Su-Shee shiny onion :) 13:49
LylePerl I prob should have discussed it with you guys first, but I wanted to be sure the uni would go ahead before taking up your time 13:50
I've seen that other Perl groups have done things like fly some of you in to talk
Unfortunately our group is still new and doesn't have any rich/well off sponsors :( 13:51
Although if any of you happen to be in the UK at that time, it would be great if you popped along
My knowledge of Perl 6 is still very limited 13:53
I need to form a list of areas for the worksgroups to look into (details of workshop format on the site) 13:54
14:09 go|dfish joined 14:22 hercynium joined, nihiliad joined 14:30 PZt joined
LylePerl I think at the end of the workshop, after the talks, it's also be good to talk to people about easy ways they can contribute to Perl 6 14:34
sjohnson das perl 14:35
14:35 Baggiokwok joined 14:37 rhr joined 14:54 Patterner joined 15:00 dugg joined 15:01 lichtkind joined
lichtkind cheers 15:02
15:02 colomon2 joined
lichtkind is here anybody that can me tell something about elf? 15:03
pmurias LylePerl: how do you imagine to workshop to look like? groups of people reading the synopsis and typing stuff into rakudo trying to figure how things work like? 15:11
15:17 Baggiokwok left, PacoLinux joined 15:25 pmichaud joined, Su-Shee joined
pmichaud good morning, #perl6 15:28
15:28 nbrown joined
colomon2 morning! 15:34
15:36 cognominal joined, Psyche^ joined, Psyche^ left, Patterner left 15:44 mikehh joined
colomon2 pmichaud: I'm very excited to see lazy gather / take up and running. 15:47
pmichaud yes, but as you noted, there's a bug in grep.
I'm looking at that now.
15:48 cotto joined
colomon2 If you mean the strange bug with the second iterator overriding the first, I think that's got to be a gather / take bug. At least, grep's source code is very simple, and (barring the wierdness with $_) worked fine with the old gather / take. 15:49
pmichaud actually, I think the problem may be with grep 15:50
the grep is using 'for', which is eager.
(not in spec, but in the current ng1 implementation for is eager)
colomon2 oh.
pmichaud yes, switching to map seems to have.... issues 15:51
hmmmm
15:54 mikehh left
pmichaud hmmmmm 15:54
ohhhhhh
no, that's not it. 15:55
hrm.
even when I switch .grep to not use map at all, I end up with the problem
sorry
let em rewrite
even when I switch .grep to not use gather/take at all, I end up with the problem
colomon2 really?
pmichaud yes
15:56 mikehh joined
colomon2 hmmm.... rangeiterator bug? 15:56
pmichaud wouldn't think so, but possible
let me reset locally and try again
and I'll commit a patch so you can play along too :-)
colomon2 Thank you.
In theory I'm cleaning my office, but I've sneaked a log-in from my office machine onto the MacBook in the other room so I can hack on ng1 a bit, too. :) 15:57
doesn't seem to be any difficulty running two RangeIterators in "parallel". 16:01
16:02 Patterner joined
pmichaud nopaste.snit.ch/19419 # problem with multiple greps 16:03
notice there's no gather/take involved there.
16:04 diakopter joined, ChanServ sets mode: +o diakopter
colomon2 yup. 16:05
16:05 diakopter sets mode: +oooo TimToady pmichaud moritz_ obra, diakopter sets mode: +oooo sunnavy Tene colomon cotto
pmichaud I'm thinking it has to be an issue with the closure block 16:05
16:05 diakopter sets mode: +o jnthn
diakopter g'morn 16:06
pmichaud yes, that's it 16:07
there's no clone taking place
I wonder which will be faster, though -- writing grep using .map and gather/take or using .map and next 16:08
16:09 mikehh left, mikehh joined
colomon2 or even writing grep as an iterator of its own... 16:11
pmichaud I'd probably vote against that
colomon2 is worried that colomon just quit.
diakopter heh 16:12
16:13 diakopter sets mode: +vvvv buubot _ilbot2 ilogger2 IRSeekBot, diakopter sets mode: +vvv lambdabot lisppaste3 pugs_svn
diakopter oh, no dalek 16:13
<frown>
feather is happily very responsive
16:13 ChanServ left, wolverian joined
pmichaud looks like a problem with whatever code is blessing closures into Block 16:14
16:15 mikehh left
pmichaud has a serious "wtf?!" moment upon seeing the Block code 16:15
16:15 dalek joined 16:16 diakopter sets mode: +v dalek 16:17 mikehh joined 16:19 tylerni7 joined 16:23 pnate joined
colomon2 My wife shut down the MacBook Pro, which is where colomon was logged in. Also, unfortunately, where my ng1 build is. 16:24
pmichaud np -- the problem is in the closure handling code
colomon2 so, might that also explain why grep was getting the wrong $_?
That is, it was getting from from grep's calling point, rather than inside the grep code. 16:25
like
pmichaud grep isn't getting the wrong $_
it's getting the wrong block
colomon2 ng: (1...10).grep({ say $_; })
oh, bother, no dalek.
diakopter it's here
oh, p6eval 16:26
sec
16:27 p6eval joined, diakopter sets mode: +v p6eval
diakopter ng: (1...10).grep({ say $_; }) 16:27
p6eval ng 22b55c: OUTPUT«Mu()␤Mu()␤Mu()␤Mu()␤Mu()␤Mu()␤Mu()␤Mu()␤Mu()␤Mu()␤»
colomon2 yeah, that problem there.
diakopter++
pmichaud ng: (1...10).say 16:28
p6eval ng 22b55c: OUTPUT«12345678910␤»
pmichaud yes, it may indeed be the same problem
at any rate, closure creation seems messed up at the moment
colomon2 I'm pretty sure that if we can fix that, grep.t will pass. :) 16:29
pmichaud and quite a few other things using map or anywhere that we pass a block as aparam
16:30 mikehh left 16:35 mikehh joined
LylePerl pmurias: I guess so... It's a bit of an experiment, i think it'll be interesting to see what people come up with... I really want to encourage them to look into it for themselves, rather than being told. So they get the bug, go home and keep going into it 16:36
colomon2 afk: dim sum 16:37
pmichaud afk, breakfast 16:39
16:50 _ash joined 16:52 Vyg3R joined 16:54 ejs joined 16:55 omps` joined 16:56 mikehh left, dakkar left 16:58 omps` left, mikehh joined, omps joined 16:59 justatheory joined 17:02 Vyg3R left 17:11 _ash left 17:12 _ash joined 17:14 _ash left 17:15 ejs left, arthur-_ joined 17:18 justatheory left 17:19 mikehh left, spinclad joined 17:21 Chillance joined, mikehh joined 17:30 omps left 17:35 xinming joined 17:37 gabiruh joined 17:43 mikehh left
pugs_svn r29601 | lwall++ | [pm.txt] some not-entirely-nailed-down ideas for direction on Pm<18 19> 18:02
r29601 | @@ is going away, @ is decoupled from flattening, coercions/contextualizers always
r29601 | take a parcel, not a list. Some speculations on how map/grep should rewrite sigs
r29601 | to be more like subpattern matches.
18:05 jql joined
diakopter using depth = UInt32; public class Block : PrototypeChain<depth, Block> { 18:07
jnthn: check out that class declaration :D 18:08
diakopter starting to reap the fruits of implementing PrototypeChain<TKey, TValue> in C# 18:09
what's even more interesting is that Block's derived classes themselves (and the derived classes thereof) are actually compiled-to-classes representations of a string->slot closures system itself (which can less efficiently be represented as a PrototypeChain<string, VarSlot>) 18:12
codegen is fun. 18:13
18:27 jan_ joined 18:29 nihiliad left 18:30 k23z__ joined 18:34 breinbaas joined 18:55 s1n joined 19:00 justatheory joined 19:01 k23z__ left 19:06 k23z__ joined 19:13 ejs joined 19:22 justatheory left
pmichaud anyone have any suggestions for a warm sunny place to vacation next weekend? Hopefully not too difficult to reach from DFW? ;-) 19:34
19:38 akl joined
pmichaud TimToady: From the latest pm.txt: 19:40
Therefore list($a) and $a.list should do the same thing, if indeed
it's a coercion. But again, that thing it's doing is something
...
TimToady Um 19:41
pugs_svn r29602 | lwall++ | [S02,S03] start detangling sigils from other contexts
r29602 | No longer use .list to mean force-flat semantics
r29602 | "List" now always means lazily contextual.
r29602 | Use .flat or .slice to be specific about that
r29602 | @@ is starting to go away (don't have sig relief for slices yet)
r29602 | @ no longer means .flat
r29602 | @($x) and @$x defined to be identical
r29602 | Foo($x) and $x.Foo defined to be identical for any known Foo type
pmichaud okay, reading update.
pugs_svn r29602 | Args to coercions always passed as parcels, not flat lists
diakopter watches hope meter change direction to clockwise 19:42
pmichaud I think I should've found a way to ask some of these questions long ago :)
TimToady diakopter: don't index your hope meter to the 3rd derivative :P
lichtkind diakopter: thanks for your time yesterday 19:43
TimToady now has to think about signature relief for flat/slice binding, and contemplate (shudder) an S09 rewrite... 19:44
pmichaud TimToady: you prefer RangeIter to RangeIterator ? 19:45
diakopter Ranger
TimToady I'd like -Iter to be a productive suffix
pmichaud that's fine, just verifying
TimToady hmm, we could even do Range-Iter, Seq-Iter and avoid Camel-Case 19:46
pmichaud well, that's still CamelCase of a form, just hyphenated :-)
I prefer non-hyphen, myself.
Don't know why.
TimToady is fine
just didn't like that MyTypeIterator kept causing column overflow
pmichaud agreed
RangeIter is fine 19:47
but the base type is still "Iterator"
(which is fine, just confirming)
TimToady yes, though it was kinda woggly there for a bit :)
pmichaud oh dear, I have to go re-think and readjust all of my terms again
TimToady had it as Iter for a while, then changed back
pmichaud Scalar(...) is back in the picture?!?
*sigh*
TimToady maybe not, but I wanted to name a role 19:48
pmichaud we still have C<list> ?
TimToady something that hides an intrinsically flattenable object
it's pretty much a no-op
might go away 19:49
pmichaud Seq doesn't autoflatten?
that's.... icky.
TimToady Parcel does
pmichaud right, but Seq does Iterable
and (at least as of yesterday) Iterable flattens 19:50
TimToady well, that one might go back the other way
pmichaud what I have currently in ng1, which seems to work _really_ well (more) 19:51
anything that is Iterable flattens, but things in scalar containers don't flatten
TimToady was thinking of it more like Scalar[Seq], so maybe the Scalar container is in need of a handier name
what are you calling it currently
pmichaud so, [1,2,3] is a scalar reference to an Array
currently it's Perl6Scalar (an internal name) 19:52
TimToady well, Ref is available :)
pmichaud one thing I'm not quite so sure about though (more)
TimToady but maybe it means AntiIterable 19:53
pmichaud sub foo() { return $x; } # the result of foo() doesn't flatten by default
however
TimToady comes back as ($x)
pmichaud sub foo() { return $x.list; } # the result of foo() does flatten, because it's not a scalar
TimToady well, that's why we're splitting .list from .flat 19:54
$x.list wouldn't flatten now
pmichaud well, .flat is different here
I see three cases
$x - return something that doesn't flatten at all (unless explicitly commanded to do so) 19:55
$x.list - return something that flattens if placed in a flattening context
$x.flat - force whatever is returned to be flattened, regardless of context
TimToady that seems right
pmichaud that's why .list is slightly different from .flat
.list is "can flatten", while .flat is "must flatten" 19:56
TimToady well, that's why .list is slightly different from a no-op, when there's only one thing
pmichaud right
TimToady list($x) likewise
pmichaud so, that was my question I started before the above
for $x, $y { ... } # two iterations, yes? 19:57
for list($x) { ... } # one iteration? or depends on $x ?
TimToady depends on $x
pmichaud okay, that's a newish behavior then
[$x] - array with one element 19:58
TimToady but should be same as $x.list by new def
pmichaud [list $x] - array with number of elements determined by $x
TimToady yes
pmichaud [list $x,$y] - array with two elements
TimToady yes, list is no-op on a list :)
well, strictly, on a Parcel
pmichaud for $x { ... } # one iteration, regardless of $x ?
TimToady correct 19:59
pmichaud what's the equivalent .map?
TimToady map {...}, $x
pmichaud there's not a method-based equivalent?
TimToady item($x).map 20:00
pmichaud and for $x,$y { ... } is equivalent to item($x,$y).map ?
(until now my mental model for "for ... {block}" had been list(...).map({block}) ) 20:01
(but that no longer works.)
TimToady why wouldn't it? 20:02
pmichaud because for $x {block} is not the same as list($x).map({block}) in the new scheme
I had been distinguishing "in list context" from "value as a flattenable list" 20:03
(the former was list(), the latter was .list)
so, list($x) was $x in list context (doesn't flatten), while $x.list was "$x as a flattenable entity" 20:04
TimToady I see what you're saing
y
20:05 Chillance left
TimToady the latter wants to be something more like $x.iterable seems like 20:07
or $x.unwrap, or some such 20:08
pmichaud well, it can be @$x, if the @ implies Iterable
TimToady but I'd like to keep the notion of lists as orthogonal to the flattening decision as possible now 20:09
so .list is probably bad for that
pmichaud but I'm still not sure how to translate for ... {block} to an equivalent map
(a method based form, at any rate) 20:10
oh, perhaps it's
[...].map({block})
TimToady don't see why we need an array
pmichaud well, we want something that imposes list context but doesn't flatten scalars 20:11
could be list($x,Nil).map({block}) instead
TimToady well, maybe list should do that, even for list($x), which would be a no-op
and we unwrap a $x elsewise
pmichaud well, if list() does that, it seems like it's no longer orthogonal to the flattening decision :) 20:12
TimToady list would always be lazy context, flattening agnostic
the choice depends on the map's block's sig 20:13
likewise for for
list($x) wouldn't be a nop-op, it would be a trivial list
pmichaud basically, ng1 has it that list($x) forces a parcel iteration of $x instead of itemizing $x out of the parcel 20:14
TimToady a Parcel, perhaps
pmichaud or, more precisely
list(...) forces parcel iteration of the ..., even if it has only one item in it 20:15
put a different way, list($x).flat doesn't flatten $x, while ($x).flat would
or perhaps the way to think of it is... 20:17
(we can change names)
list($x).foo # forces .foo to be invoked on the parcel containing $x
($x).foo # invokes .foo on $x directly
so perhaps list() is really Parcel($x) 20:18
but that gets ickyish in other respects
TimToady kinda like (\($x)).foo 20:19
pmichaud it might be worth noting that in ng and ng1, the parcel constructor is infix:<,>
and so ($x) really isn't a Parcel anyway
(except conceptually)
TimToady well, any item that isn't a Parcel is degenerate parcel 20:20
pmichaud right
20:20 allbery_b joined
pmichaud and what list(...) currently does is create a Parcel containing (...), and then a List (iterator) that iterates the Parcel 20:21
so list($x) really creates a flattening iterator for a non-degenerate Parcel containing $x
TimToady sounds good to a brane that is short on nutriments... 20:22
20:22 nihiliad joined
pmichaud well, let me re-read the updated specs and see if I can tease out the semantics of the new definitions 20:23
TimToady a non-degenerate Parcel sounds like a Ref
pmichaud maybe, but I want iteration to be different
iterating a Parcel with one item should not iterate the one item (if the one item is non-flattening)
that seems different to me than a Ref 20:24
TimToady a Parcel that pretends it has multiple elements when it only has one 20:25
pmichaud right
thus my ($x,Nil) version above
TimToady a way to defeat the auto-deref that usually happens
pmichaud but that's what list() currently does in ng1 -- it creates an iterator for a Parcel that doesn't degenerate if there's one item 20:26
(conceptually, because it's not possible in ng1 to create a Parcel with one item atm)
TimToady munchings and crunchings & 20:27
20:27 ejs left
pmichaud I need to think on it just a bit more, but perhaps a very useful distinction is to think that infix:<,> creates a Parcel, and postcircumfix:<( )> creates a Parcel, (and maybe other postcircumfixes as well), but circumfix:<()> _doesn't_ create a Parcel 20:29
then we might be able to eliminate the notion of "degenerate Parcel"
(exception, empty parens create an empty parcel) 20:30
so, ($x) doesn't have a Parcel in it at all, even conceptually
and a Parcel of one element doesn't degenerate
afk for a bit 20:32
back for a sec: and we have some other operator or mechanism for creating a parcel of one element 20:34
TimToady and \$x creates a Parcel
pmichaud I somewhat prefer that \$x creates a Capture, but okay 20:35
I might need to re-think that into my model as well
there's always Parcel($x) for creating a Parcel of one element
TimToady captures are very minor in my mental picture, a last-minute optimization of parcels where we know we might want named params
pmichaud well, that's a good question as well 20:36
what's the effect of |$x if $x is a hash?
TimToady inserts the pairs into the parcel, which might or might not promote to capture 20:37
pmichaud well, in foo(|$x), for example
if $x is a Hash, does it act like named arguments there?
TimToady I think it's supposed to, currently 20:38
making lunch, so distracted 20:39
pmichaud that's fine
how would I pass pairs as positional arguments?
I guess convert $x to an array and | that? 20:40
foo(|@$x) # always positional
foo(|%$x) # always named
foo(|$x) # depends on $x
TimToady $x could be a capture and do both
pmichaud right
TimToady or a match 20:41
20:41 ejs joined
pmichaud okay, I can live with that 20:41
TimToady I think I like non-degenerate parcels
pmichaud yes, it's worked out very well in rakudo (master, even)
TimToady the fact that we're having to invent them to get around the degeneracy..
lunch &
pmichaud okay, I'll continue probing with the "no degenerate Parcels" concept also 20:42
but now a short break to go pound on a drumkit
20:42 nihiliad left 20:48 k23z__ left 20:49 k23z__ joined 20:57 colomon joined 21:08 ejs left
obra win 2 21:12
21:15 nihiliad joined 21:27 tmosx joined
tmosx Hello everybody, is it possible to print the variable name instead of its value ? for example : $x would print x and not ( 5, which is its value)? 21:28
21:34 PerlJam joined 21:40 nihiliad left 21:43 tmosx left
TimToady pmichaud: \$x can't be just parcel, or it won't protect from flattening, so that's gotta be a different indirection 21:52
21:54 eternaleye joined
Tene pmichaud: did you get my note I left in #parrot last night? 21:56
colomon Tene++ # gather / take 22:00
Tene colomon: the problem only shows up when you make other iterators before using them 22:01
colomon eh?
Tene didn't you report a problem with gather to me last night? 22:02
22:02 nihiliad joined
colomon I think pmichaud determined the problem I found wasn't gather / take at all. 22:02
Tene Ah. I haven't read scrollback.
colomon He reimplemented grep using map instead of gather / take, and it still has the issue. Something to do with cloning closures. 22:03
(he thinks, but it sounds right to me.)
Tene yes
colomon so you're totally off the hook for that, and we're left with your cool lazy gather / take. :) 22:04
22:07 diakopter sets mode: -q $~a
diakopter in case it was set 22:07
pmichaud Tene: no, didn't get the message yet (picking up messages now) 22:11
Tene pmichaud: colomon says that you already found the problem, something about cloning closures. 22:12
pmichaud right
something isn't getting lexicals and closures correct
I suspect a closure might not be cloned properly. Although that doesn't quite match the symptoms either
anyway, it's pretty clearly not a gather/take problem, since I get the same issues when using a straight map 22:13
Tene I nopasted a restricted example that might help 22:14
pmichaud and it's also obvious from looking at the generated code that closures aren't being cloned
Tene nopaste.snit.ch/19418
pmichaud the restricted example works the way you expect, or doesn't?
Tene there's a line commented out. it works when uncommented, and misbehaves when commented. 22:15
pmichaud okay
did you pull in my coroutine cloning changes, ooc?
Tene No.
22:15 nihiliad left
pmichaud that might be why it's not behaving, then. 22:15
but I'm also certain there are issues with the various thunk routines in actions.pm 22:17
colomon actually, it fails with the latest code checked in, too.
(just checked)
pmichaud okay, looking.
that still sounds like a closure cloning issue, though. 22:18
maybe the closure being passed to gather isn't being cloned 22:19
that would make a lot of sense
it's not 22:20
so, what is happening is that when the closure finally gets invoked by .get, it has the wrong outer context
colomon it's not being cloned, or that's not the problem?
pmichaud it's not being cloned, that *is* a problem
at one time I think I had PAST::Compiler automatically cloning closures... but I think "automatic" is probably the wrong approach. Maybe a flag on the PAST::Block is needed 22:22
anyway, I know that the thunking code in ng and ng1 has issues and looks in need of a significant cleanup
(looked at it in some detail this morning)
afk for a bit 22:24
22:25 k23z__ left 22:29 PacoLinux left 22:32 synth joined 22:34 [synth] joined 22:36 [synth] left, nihiliad joined 22:49 PacoLinux joined 22:55 nihiliad left, p6eval left, cognominal left, lisppaste3 left, xinming left, arthur-_ left, dalek left, pmichaud left, akl left, colomon left, pnate left, PZt left, hercynium left, tylerni7 left, synth left, allbery_b left, spinclad left, diakopter left, eternaleye left, Su-Shee left, go|dfish left, LylePerl left, PerlJam left, jan_ left, buubot left, buu left, breinbaas left, nbrown left, sunnavy left, arnsholt left, jql left, colomon2 left, cotto left, Patterner left, lichtkind left, PacoLinux left, dugg left, rhr left, s1n left, gabiruh left, wolverian left, mssmfs left, diakopter joined, jferrero joined 22:57 colomon2 joined, Khisanth joined, Helios joined, lichtkind joined, cotto joined, Patterner joined, Grrrr joined, yves joined, hicx174 joined, IRSeekBot joined, dugg joined, PacoLinux joined, huf joined, hercynium joined, xinming joined, saschi joined, jjore joined, pugs_svn joined, hatseflats joined, nsh joined, Lorn joined, frettled joined, mssmfs joined, rhr joined, wolverian joined, gabiruh joined, s1n joined, pmichaud joined, ssm joined, lisppaste3 joined, kornbluth.freenode.net sets mode: +ovvv cotto IRSeekBot pugs_svn lisppaste3, cognominal joined, p6eval joined, nihiliad joined, LylePerl joined, pnate joined, kornbluth.freenode.net sets mode: +v p6eval, sjohnson joined, phenny joined, PerlJam joined, jan_ joined, buubot joined, mj41 joined, BinGOs joined, krunen joined, constant joined, kornbluth.freenode.net sets mode: +v buubot, eternaleye joined, lestrrat joined, yahooooo joined 22:59 breinbaas joined, jql joined, nbrown joined, buu joined, sunnavy joined, arnsholt joined, moritz_ joined, elmex joined, Tene joined, stepnem joined, _ilbot2 joined, kornbluth.freenode.net sets mode: +ooov sunnavy moritz_ Tene _ilbot2, charsbar joined, cosimo joined 23:00 jrockway joined, Su-Shee joined, literal joined, kraih_sri joined, akl joined, tylerni7 joined 23:04 justatheory joined, allbery_b joined, obra joined, tomaw left 23:07 tomaw joined 23:08 Su-Shee left 23:12 tkr joined 23:14 duryodhan joined 23:15 nihiliad left 23:23 ejs joined 23:24 patspam joined 23:26 lichtkind left 23:27 PZt joined 23:35 duryodhan left 23:36 Khisanth left, Khisanth joined 23:38 go|dfish joined 23:41 eternaleye left 23:46 ejs left 23:47 eternaleye joined, eternaleye left, eternaleye joined 23:50 DarkWolf84 joined
DarkWolf84 hi there :) 23:51
23:54 DarkWolf84 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!