pugscode.org/ | nopaste: sial.org/pbot/perl6 | pugs: [~] <m oo se> (or rakudo:, kp6:, elf: etc.) (or perl6: for all) | irclog: irc.pugscode.org/
Set by Tene on 29 July 2008.
00:21 scrottie joined 00:23 xuser joined 01:07 cathyal left 01:15 explorer__ left 01:29 gnuvince_ joined
gnuvince_ Does anybody know what audreyt++ used to make the Imaginary Perl 6 Timeline? 01:29
TimToady borrowed the idea from Haskell culture; don't know what tool though 01:31
gnuvince_ I want to make a fake graph, and OpenOffice.org gives a "meh" result 01:32
ruoso gnuvince_, inkscape is handy to do that kind of stuff
gnuvince_ ruoso: thank you, I'll download it and check it out. 01:33
ruoso zZzZzZ &
01:42 sri_work_ joined 01:47 wknight8111 left 01:49 sri_work left 02:01 jrockway left, jrockway joined 02:04 justatheory left 02:07 sri_work_ left 02:12 alanhaggai joined 02:26 kst``` left, kst``` joined 02:34 xiaoyafeng joined 02:57 [particle] joined 03:02 elmex_ joined 03:04 wayland76 joined 03:06 jrockway left 03:07 jrockway joined 03:08 rdice left 03:14 [particle]1 left 03:17 gnuvince_ left 03:18 elmex left, elmex_ is now known as elmex 04:00 alanhaggai_ joined, alanhaggai left 04:36 Bzek joined 04:48 alanhaggai_ left 04:50 eternaleye joined 05:08 alanhaggai joined, kst``` left 05:09 kst``` joined 05:24 meppl joined
meppl good morning 05:25
05:33 alanhaggai_ joined, alanhaggai left 05:45 alanhaggai_ is now known as alanhaggai 05:59 Psyche^ joined 06:12 Patterner left, Psyche^ is now known as Patterner 06:29 ashizawa joined 06:51 jferrero joined 06:53 baest_ left 07:14 iblechbot joined
pugs_svn r22616 | particle++ | [t] unfudge two more passing 'is export()' tests for rakudo now that taglists are supported 07:14
07:15 cosimo joined
moritz_ wonders why autounfudge didn't catch this one 07:16
07:19 viklund joined
[particle] i just added support to rakudo for it 07:20
looks like rakudo commit bot isn't worknig
moritz_ time to fix that. 07:23
07:23 rakudo_svn left
pugs_svn r22617 | particle++ | [rakudo] add 9 more 'is export()' tests for custom tagsets 07:23
moritz_ svn: OPTIONS of 'svn.perl.org/parrot/trunk/languages/perl6': could not connect to server (svn.perl.org)
07:23 rakudo_svn joined
[particle] i'm fabulously happy 'is export()' works now 07:24
07:24 speckbot left
moritz_ indeed 07:24
[particle]++
[particle] now i can move on to importing!
07:24 speckbot joined
[particle] those tests could use better smartlinks 07:25
otherwise, i think they're good... oh, no, i still need to support :MANDATORY 07:26
i'll do that tomorrow, as i start work in < 6 hours
bed &
moritz_ good night
07:30 zamolxes left
moritz_ the rakudo_svn bot is a having a network problem, no connection to svn.perl.org 07:31
07:33 eternaleye left
pugs_svn r22618 | moritz++ | [t/spec] unfudge three passing TODO tests 07:36
07:39 xiaoyafeng left 07:58 PZt left 08:01 kst``` left 08:02 kst``` joined 08:14 pjcj left 08:15 pjcj joined 08:16 schmalbe joined 08:28 meppl left 08:30 smtms left
abz_ hi all 08:35
08:43 pjcj left 08:47 bacek joined 08:53 tomyan joined 08:56 pmurias joined
pmurias ruoso: what's wrong with the previous way of calculating the new array size? 09:11
09:12 donaldh joined 09:17 icwiener joined
pugs_svn r22619 | pmurias++ | [smop] added Array.push 09:19
ruoso pmurias, it was mixing number of elements with size in bytes.... 09:24
pmurias, then I just made the dumb fix... but I left the code there so someone smarter could have it correctly fixed ;)
pmurias ruoso: array size is in elements 09:30
09:37 agentzh left 09:40 schmalbe left 09:41 agentzh joined
pmurias ruoso: any other blockage other than push? 09:42
pugs_svn r22620 | pmurias++ | [smop] added test for unshift, switched back to amortized allocation (fixed a bug in it)
09:43 agentzh left 09:46 PZt joined 09:47 agentzh joined 10:02 Maghnus left 10:03 Maghnus joined 10:15 ejs_ joined 10:17 ruoso left, pedrob joined 10:34 bacek left 10:54 spx2 left 10:57 kst``` left 10:58 kst``` joined 11:00 spx2 joined 11:10 pedrob left
pugs_svn r22621 | pmurias++ | [mildew] generates syntacticly correct m0ld for t/pure_prototype_how.p6, lacks runtime support to run it 11:16
11:16 pmurias left 11:29 xiaoyafeng joined 11:37 sri_work joined 11:39 alester joined 11:43 sri_work left, speckbot left, rakudo_svn left, abz_ left, spinclad left, bjorn` left, jfredett left, idemal left, integral left, Tene left, cj left, SamB left, tcliou left, xiaoyafeng left, Patterner left, Bzek left, xuser left, pmurias_ left, REPLeffect left, jjore left, mtve left, PerlJam left, alester left, PZt left, viklund left, iblechbot left, scrottie left, jhorwitz left, araujo left, TimToady left, Guest16015 left, kolibrie left, TreyHarris left, moritz_ left, meteorja1 left, hcchien left, orafu left, ilbot2 left, preflex left, buubot left, sirhc left, falesca left, IRSeekBot left, mj41 left, drbean left, TimToady joined, alester joined, sri_work joined, xiaoyafeng joined, PZt joined, speckbot joined, rakudo_svn joined, viklund joined, iblechbot joined, Patterner joined, Bzek joined, xuser joined, scrottie joined, abz_ joined, pmurias_ joined, jhorwitz joined, araujo joined, orafu joined, tcliou joined, bjorn` joined, jfredett joined, sirhc joined, TreyHarris joined, drbean joined, mj41 joined, REPLeffect joined, PerlJam joined, idemal joined, Guest16015 joined, spinclad joined, meteorja1 joined, moritz_ joined, Tene joined, cj joined, ilbot2 joined, IRSeekBot joined, buubot joined, falesca joined, kolibrie joined, preflex joined, hcchien joined, mtve joined, SamB joined, integral joined, jjore joined, irc.freenode.net sets mode: +o TimToady 11:46 wayland76 left 11:54 iblechbot left 11:55 icwiener left 12:00 Maghnus left, tomyan left, ashizawa left, alanhaggai left, [particle] left, kanru left, ting left, clkao left, smg left, diakopter left, allbery_b left, lisppaste3 left, kst``` left, literal left, Torment left, _Jedai_ left, cxreg left, bennymack left, gantrixx left, avar left, jiing_ left, c1sung left, donaldh left 12:01 Guest70230 left, japhb left, yves left, Caelum left, simcop2387 left, cookys left, audreyt left, jiing left, pasteling left, c9s left, kst``` joined, Maghnus joined, donaldh joined, tomyan joined, ashizawa joined, alanhaggai joined, [particle] joined, literal joined, Torment joined, _Jedai_ joined, kanru joined, cookys joined, simcop2387 joined, gantrixx joined, smg joined, lisppaste3 joined, c9s joined, Caelum joined, c1sung joined, diakopter joined, cxreg joined, jiing_ joined, avar joined, allbery_b joined, ting joined, bennymack joined, clkao joined, audreyt joined, yves joined, japhb joined, jiing joined, Guest70230 joined, pasteling joined 12:09 alester left 12:22 smtms joined 12:38 iblechbot joined 12:43 alester joined 12:46 kst``` left 12:47 ashizawa left 12:58 alester left 12:59 zamolxes joined
jferrero is away: Ocupado... ahora vuelvo... 13:02
13:13 ejs_ left 13:20 donaldh left 13:38 kst``` joined 13:59 pedrob joined 14:04 adc_Penner joined
[particle] TimToady: the :MANDATORY tagset is mentioned only once in S11, in an example. are routines marked with :MANDATORY also injected into :DEFAULT? i suspect so, and am coding that in now, but it's a bit ambiguous since there's no other mention. 14:04
14:05 TJCRI joined
[particle] and there's nothing about how :MANDATORY should be respected during importation. 14:05
sorry, i suspect *not*. that is, :MANDATORY ends up in :ALL but not :DEFAULT. 14:07
pugs_svn r22622 | particle++ | [t] add tests for :MANDATORY tagset 14:09
TimToady the lists are independent, so where you put which names depends on the algorithm
if you always just shove :MANDATORY at the front of the import tags, then whatever is there need not be anywhere else 14:10
[particle] the lists are dependent except for :ALL i assume
14:11 spx2 left, spx2 joined
TimToady so even if they import :ALL, if :MANDATORY is before that, those don't have to be in :ALL 14:11
that being said
it would be good for :ALL to actually document that it has all of them
[particle] yes, that's the way i've implemented it
TimToady so in the case of :ALL you don't need to do :MANDATORY stuffing 14:12
doubtless there are various fancy ways to do set theory and avoid trying to make duplicate links
but brute force is probably not terribly slow 14:13
[particle] my take is everything ends up in :ALL and the other tagsets you specified, if any
TimToady plus :MANDATORY stuffing if you don
don't say :ALL
or are you putting those everywhere 14:14
?
that works too, I guess
[particle] :MANDATORY only goes into ::MANDATORY and ::ALL
s/only//
TimToady then when you say :FOO how does :MANDATORY come in? 14:15
[particle] it doesn't
TimToady it's supposed to
that's why it's :MANDATORY
[particle] sub baz is export(:MANDATORY) {...} # (always exported)
that's the only mention
TimToady which means it has to get linked alwasy, even if they say use Module :FOO 14:16
14:16 Khisanth left
[particle] yes, but that's import, not export. 14:16
and that's where i have questions.
use Foo; imports ::MANDATORY and ::DEFAULT
TimToady to the first approximation, it just picks the subpackage and binds all the names it finds there 14:17
yes
[particle] the question is, can import be overridden
TimToady by whom?
[particle] the user, by specifying an IMPORT sub/method 14:18
TimToady as in Perl 5, just write your own bindings
only with := instead of typeglobs 14:19
but then you probably don't want to say "use"
[particle] just wondering if custom import routines need to respect :MANDATORY exporting
or if that's builtin to use/require
seems like it's builtin, and that works fine for me
TimToady custom routines can do whatever they like 14:20
[particle] okie, fine. time to update use/require!
thanks.
TimToady but the reason for using mandatory is probably that it's a language-bending module, and if you don't import the macro, you don't get to access it except as a sub
[particle] right. that's fine for now, and we're a while away from macro support so i don't need to worry about it 14:22
(yet).
from my read on exporting, any routine is assumed to be exported unless it's marked 'only' or 'my'. 14:23
is that correct?
Any proto declaration that is not declared "my" is exported by default. Any multi that depends on an exported proto is also automatically exported. When there is no proto for a multi, the autogenerated proto is assumed to be exportable.
TimToady that seems about right 14:24
multis try to be everywhere, other things try to stay private 14:25
[particle] gotcha.
14:25 xinming_ left
TimToady in most languages with multimethods they're just automatically global 14:25
but globals are evil so we're trying to finess it via the export system 14:26
*finesse
language changes are lexically scope in P6
*scoped, can't type this morning
14:26 Khisanth joined
TimToady that's because my coffee isn't done yet 14:27
well, age-related brain rot couldn't have anything to do with it... :)
pmichaud 14:23 <[particle]> from my read on exporting, any routine is assumed to be exported unless it's marked 'only' or 'my'.
I didn't read it that way.
[particle] s/routine/multi/ 14:28
pmichaud okay, that I can agree with.
[particle] timtoady read it right, even though i typed it wrong
TimToady bleah, the problem with making coffee without having made coffee first is you aren't awake enough to make coffee correctly... 14:30
TimToady forgot to turn on the coffee pot :(
NOW EVERYTHING I SAY WILL HAVE BEEN WRONG!!! :) 14:31
including that... 14:32
PerlJam Is that Rule 0? All rules subject to the appropriate amount of coffee.
14:33 bennett joined
[particle] doesn't know if TimToady forgot the period after the ellipsis, or if he misspelled it 14:33
TimToady I don't believe in 4-dot ellipses.
if there's a space after it, it's the end. 14:34
well, a whitespace...
the real problem is that, while you can use em-dash for pause in the middle of a sentence, it looks strange at the end of a sentence. 14:36
So end-of-sentence pause ends up usurping ... when it doeesn't quite mean "something was removed here"
it means more like "and there are further implications I'll let you work out for yourself"
14:37 agentzh left
TimToady PerlJam: I don't know if the coffee series has a neutral value. :) 14:38
[particle] following that, it seems a leading emdash should mean "it is obvious that", but that's not common usage yet.
TimToady what I like is the Japanese usage a thought bubble with ... in it to mean "unspoken cogitation/confusion happens here" 14:41
usage of
PerlJam
.oO(...)
(A bit much to type perhaps :)
TimToady ... 14:42
...___...
[particle] save our ship? 14:43
or is that russian for bear?
14:45 pedrob left 14:46 pedrob joined 14:47 Lorn left
TimToady maybe that's how the infix:<...> operator is pronounced. "one, two, three ssss whatever" 14:47
14:48 alc joined
[particle] dit dit dit vs yadda yadda yadda 14:50
14:51 alester joined
jferrero is back (gone 01:49:29) 14:51
14:52 zamolxes left 14:53 agentzh joined
TimToady you're so...ditzy... 14:58
[particle] *rimshot* 14:59
15:07 bennett left 15:08 Lorn joined 15:09 pedrob_ joined 15:10 viklund left 15:21 hercynium joined 15:26 pedrob left 15:32 speckbot left, rakudo_svn left 15:39 cosimo left, Exodist joined 15:45 spx2 left, spx2 joined 15:46 tomyan left 15:53 xiaoyafeng left 16:01 xuser left 16:04 meppl joined
meppl good evening 16:05
16:06 xuser joined, spx2 left
moritz_ hi 16:07
16:08 alanhaggai left 16:11 orafu left 16:12 ZuLuuuuuu joined 16:18 pedrob_ left 16:19 alc left, justatheory joined
pugs_svn r22623 | lwall++ | [t/] no more unpacking hash parameters, s/ceil/ceiling/ 16:21
16:23 rdice joined 16:29 kst``` left, kst```` joined 16:32 alanhaggai joined 16:35 pjcj joined 16:41 mncharity joined, alanhaggai_ joined, alanhaggai left 16:42 orafu joined 16:45 alanhaggai_ is now known as alanhaggai 16:48 ZuLuuuuuu left
mncharity ok, let's see... 17:17
svn up'ing and rebuilding src/perl6 is like christmas, unwrapping presents. :)
17:17 Bzek left
moritz_ developrs-only christmas ;) 17:17
mncharity lol 17:18
good concept. I've always worried the p6 xmas model was two binary - someday, it's suddenly done. 17:19
moritz_ well, in real life christmas comes all suddenly as well
mncharity a staged xmas - xmas for compiler devs, xmas for prelude work, xmas for non-production coding, xmas for production, etc, has appeal
moritz_ indeed 17:20
17:23 jferrero left
TimToady "two binary" is an interesting freudian slip 17:26
mncharity lol 17:33
17:34 demq joined 17:41 sri_work left
[particle] looks like nested packages aren't far from working in rakudo, that's good news. 17:41
17:51 ruoso joined
mncharity indeed 17:53
ruoso Hello! 17:56
mncharity hi ruoso :) 17:57
ruoso hi mncharity
[particle] hola
17:57 alester left 17:58 _Jedai_ left
ruoso [particle], have you seen the latest developments on the lexical multi thing? 17:58
[particle], it should be relevant to parrot's implementation...
17:58 Jedai joined
[particle] no, i haven't paid much attention to scrollback here, just the ml 17:59
if it's discussion from yesterday, i was more-than-half distracted by a phone call 18:00
ruoso [particle], ok... try to take a look at yesterday's log... but basically, the idea is that a Multi object needs to hold a reference to the scope at which it is declared, as well as storing a name
because when you .() at a multi, it needs to do full dispatch
including variants not declared in the same level of the current multi object
[particle] unless it's my, i suppose
ruoso [particle], even then... 18:01
it still sees the outer declaration
TimToady calling these things Multi is confusing things
moritz_ I think the usual attitude is "I'll care about it when I implement" ;)
TimToady a Multi is not a multi
[particle] ah. capitalization will be the death of me
TimToady it's a ShortName, really
ruoso right... Multi is not even a type in Perl 6...
moritz_ [particle]: no, Capitalization ;) 18:02
18:02 explorer joined
[particle] *stab* *stab* *stab* 18:02
mncharity capitulation
ruoso maybe SubCandidateContainer
TimToady it's what the compiler knows about &foo at the point of the call
ruoso MultiContainer
TimToady Ballot 18:03
vote for one
ruoso Ballot is cute, but too generic
[particle] SpecificBallot
TimToady I don't care, as long as whatever you call it doesn't confuse poor [particle]
[particle] :P
ruoso ohkay 18:04
I'll call it MultiContainer then
because it's what it is (sort of)
so...
every lexical declaration creates a new MultiContainer object
[particle] it's a dispatch table
ruoso [particle], not really... and that's the poitn
TimToady it's a candidate list, which is why it's a Ballot
ruoso it's more than a dispatch table 18:05
because it needs to traverse the lexical scope to find additional candidates
18:05 AzureStone left
ruoso it stores just some candidates (unless counting cache, which I see as optimization) 18:05
[particle] it's the thing against which you match the current sig
ruoso [particle], no... that's each candidate sig
[particle] ok, right, it's the thing that holds the things against which... 18:06
TimToady you have to have signatures to put something on the ballot :)
[particle] how many parties are on the ballot? is this a one-party system? 18:07
ruoso the innermost MultiContainer only holds the innermost declaration
TimToady if you did match a signature against one of these things, you 'd end up with a shorter candidate list
how many parties there are is controlled geographically in Perl 6 18:08
aka lexically
ruoso geez... even I am confused now...
let me try to re-state
[particle] is the ballot traversed by candidate, then by party? 18:09
ruoso MultiContainer is the thing that hold each multi candidate
mncharity lol #re geez :)
[particle] s/each/every/
TimToady [particle], forget parties
[particle] s/party/lexical scope/ 18:10
ruoso It doesn't hold *all* multi candidates
only the candidates declared at the same lexical scope
[particle] ah, ok.
gotcha.
ruoso that's why it needs to keep a reference to the outer scope, and it also needs to know its name
TimToady er, it can hold all from locked down scopes
it really only has to treat packages as dynamic, once CHECK is done 18:11
ruoso TimToady, I'm trying to leave that to optimization...
TimToady I'm trying to leave wiggle room for the optimizer :)
but yes, in theory this can all be done at run time 18:12
ruoso and when you $multicontainer.() it does a full lookup in the lexical scope to find *all* candidates, before matching the signature
[particle] package Foo { multi baz(Int $x) {...}; package Bar { multi baz(Int $x) { ... }; multi baz(Set $x) {...} } }
ruoso that's an error or at least a warning 18:13
but I'd guess it's an error
[particle] where did i go wrong?
ruoso because you're redefining multi baz(Int $x)
TimToady in an inner scope
[particle] in a subpackage
TimToady so it's okay
it just hides the outer one 18:14
ruoso is it ok because it's an inner scope? or because it's a inner package?
[particle] ok. great, that's the answer i was looking for.
TimToady scope 18:15
ruoso package Foo { multi baz(Int $x) {...}; package Bar { multi baz(Set $x) {...} } }
TimToady however, being a package it's subject to redefinition on the fly
ruoso [particle], the example above exposes the exact issue I'm pointing at
[particle] package Foo { multi baz(Int $x) {...}; { multi baz(Int $x) { ... } #{hides outer multi} } } 18:16
TimToady you can't be in package Foo simultaneously with backage Bar
*package
when the candidate list is being constructed, only the current package is consulted in the list I gave yesterday
ruoso right... but it's still in an outer scope 18:17
which makes it visible
18:17 greatflamingfoo joined
TimToady by virtue of "our"ness 18:17
ruoso yes
TimToady but not by virtue of being in the package
ruoso yes
TimToady if the candidate search stops short of the package, then it degenerates to the "my" situation 18:19
otherwise an our multi is actually visible two different ways 18:20
in the lexical scope, and in the package
ruoso yes...
TimToady so it hides itself in that case :)
ruoso it seems so...
18:20 icwiener joined
TimToady anyway, I think we understand the thing on a procedural level 18:21
ruoso it looks like you start harvesting candidates from the Package,
then scopes
putting on a hash
TimToady ....
ruoso in a way that newer candidates that share the same signature are overwritten by the innermost candidate
TimToady well, assuming it's keyed on longname 18:22
ruoso yes
TimToady but you could also go the other direction and avoid putting it in if it's already there
ruoso right...
TimToady just depends on which kind of treewalk you want to think of it as 18:23
ruoso it actually makes more sense to go from inside to outside...
to stop when you find a proto
TimToady and there could be other non-idempotencies that would "encourage" harvesting the info as soon as possible 18:24
ruoso by pre-caching, you mean?
TimToady well, if you hit a perfect match for the signature, you can just stop and call it, I think 18:25
s/signature/capture
pmichaud at present rakudo cheats by storing everything in terms of its shortnames 18:26
ruoso is there a way to know that it is a perfect match?
TimToady assuming the initial "can match" decision is made at the same time, which is not clear
pmichaud when we get to seriously considering multies, that will change. Then the shortnames will keep track of multiness (where appropriate) and the subs will be held by their longnames
*multis 18:27
TimToady once we start optmizing, there is probably a hashed type profile that can be compared to determine that we already know exactly how to dispatch this Capture
so a capture containing (Int,Int) has a particular identity that can match a sig (Int,Int) in one numeric comparions 18:28
s/ons/son/
pmichaud I kinda like "comparions"
that's what we'll call the hashed type profile :-P
"it's a hash of comparions" 18:29
TimToady yes, the Dan design was to just call an "only" sub of the shortname that emulates multi for you
ruoso that's kinda what we're getting at now 18:30
TimToady the interesting question to me is how this is gonna show up on platforms that don't treat functions as first-class objects, like P5 18:31
ruoso as something opaque that produces the expected result? 18:32
TimToady Makes it hard to ask: "Don't do it, but if I were to ask you this, what would be your result?" 18:33
ruoso er... that isn't really possible in P5 anyway, is it?
TimToady kinda like "Look up this subscript, but not really, just tell me if the last operation would succeed" 18:34
well, there are hacks...
ruoso like... looking at the optree?
well these hacks wouldn't work...
as they don't work with XS subs 18:35
TimToady but it'd be nice not abstract everything into real P5 objects when the overhead is unnecessary
ruoso TimToady, I don't think it will be necesssary
nothingmuch and mst have been experimenting some cool things in P5
TimToady well, the whole gimme5 notion is to keep it all as close to the P5-metal as possible
(which is not very close, in the case of regexen, sigh)
I figure on implementing as much on top of P5 as is practical, then seeing what hacks would make it easier to do the rest 18:36
like lazy lists maybe
ruoso I really think it will be possible to transparently interoperate SMOP objects inside perl5 at some point... 18:37
TimToady but I kinda doubt P5 as a platform will ever support all of P6
hopefully 18:38
keep peddling hard :)
ruoso actually it would be more like the other way around...
but it would be two-ways interoperating
it wouldn't be the actual p5 interpreter, but a modified interpreter running on top of SMOP 18:39
TimToady real continuations in P5 would make laziness easier
ruoso yes... making p5 trully-stackless is a reason for having a modified p5 interpreter inside smop
TimToady but I basically already know how to write a regex engine in P5 now :)
ruoso I still need to figure out a way to distinguish a SMOP__Object* from a SV* 18:40
so it can decide what to do in the runloop
TimToady steal the 1 bit? 18:41
ruoso 1 bit?
TimToady the 1 bit is always 0 in pointers to aligned data 18:42
or, if SV is aligned on 64, and yours on 32, you can steal the 32 bit and just make sure you allocate on odd 32-bit boundaries :)
or vice versa 18:43
mncharity did a parrot+ruby hybrid using that :) (low-bits, not, shudder, the 32 bit)
TimToady or if they're both 64-bit, then use two different allocators that do even or odd boundaries
you only have to waste half an entry at the beginning of a block 18:44
the real question is *how* do you want to distinguish them
using an "if" is different from just dispatching differently... 18:45
so maybe you just add a vtable to SVs :) 18:46
ruoso well... in fact I could add a RI to the SVs
considering every module would need to be recompiled
mncharity TimToady: fyi, given the STD graph for 3.a.b , if you walk the 'arg' spine, you get ((3 .a) .b), but if you walk the 'dotty' spine you get ((3 .b) .a). so viv says the right thing, but the nodes have invalid dotty's.
ruoso I could have a different SV structure
TimToady yeah, there's something duped in there, but better too much than too little, eh? :) 18:47
ruoso then the SMOP interpreter would just use the objects without seeing a difference 18:48
TimToady meanwhile I'm cogitating heavily about how to return tokens in token order, and how that impacts the meaning of $/[0] vs $<0>, and splits vs combs, and how the heck signatures can match all named parameters as positionals...
ruoso and the p5-modified-interpreter would have two dispatching mechanisms
or maybe not...
TimToady just rewrite all the cute macros that P5 uses, and you're done :) 18:49
ruoso TimToady, aren't the macros dependent on the SV struct declaration?
TimToady waves his hands vaguely
obviously you might also have to rewrite some of the missing macros that aren't there yet. :) 18:50
ruoso anyway... I'm pretty confident we'll find a way when it's time...
;)
TimToady macros are the solution to just about everything that's wrong with C, except for the problem of C macros 18:51
[particle] that can be solved by abstracting the c under a virtual machine :)
TimToady don't let me slow you down :) 18:52
ruoso the biggest problem will be the C code that recurses back into the interpreter
(it wouldn't be a problem under a vm, yeah...)
18:52 pedrob joined
TimToady just need to bribe Intel to install a few CPU hooks... 18:53
hardware support for continuations, yum
ruoso but this recursions always are represented in terms of C macros in XS, iirc 18:54
which leaves room for weird setjmp hacks
TimToady well, that was the ponie theory... 18:55
justatheory neighs
TimToady unfortunately this ponie nays
anyway, the abstract problem I'm trying to solve is that when a Match is returned, you want to be able to ask for particular named fields as well as the fields in order, but that doesn't map well to current signature binding semantics 18:57
ruoso indeed
justatheory heh
ruoso named are not ordered 18:58
justatheory That ponie don't hunt.
TimToady so I think there's something fundamental that needs to be figured out about captures and signatures
but when you ask for the tokens in order, you don't just want it to leave gaps where the names were
moritz_ aye
TimToady that's more or less what current sigs give us 18:59
ruoso hm?
18:59 icwiener left
moritz_ so if we had some raw, ordered captures, that would also remove the specialness of list() 18:59
TimToady it's like you want to be able to pull named args out of the raw list "with replacement" or without 19:00
something going on about the invocant in here as head of the list, also
ruoso isn't that you have the named elements also listed as positional elements/
?
TimToady but not sure how this relates to "make"
ruoso like.... duplicated... 19:01
TimToady it's not the pugs model
19:01 icwiener joined
TimToady which separates out the nameds at an early stage 19:01
but I think that's a problem
ruoso you think it's a problem to separate? or to not separate?
SMOP separates at a very low-level early basic stage 19:02
TimToady to separate out the nameds and lose ordering info on the original args
ruoso can we just assume that named are not positional? 19:03
19:03 kst````` joined
TimToady for "please tokenize this" you need to be able to at least reconstruct the original order of intermixed nameds and positionals 19:03
and it would be even nicer if it were efficient
ruoso in the cases it named should be positional, I could argue that they would be at the same time named *and* positional... 19:04
19:04 alanhaggai left
ruoso meaning double entries... 19:04
but that's not the nature of every capture
only a very few captures (and sigs) need this kind of semantics (I guess) 19:05
so duplicating the entry so it appears both as named and as positional could solve it
moritz_ it's not that simple for matches
pmichaud as another way of looking at things, PHP keeps the ordering of its "named" and "positional" values in its arrays 19:06
19:06 Lorn_ joined
ruoso pmichaud, but that's because it converts everything to strings... 19:06
moritz_ because multiple named matches of the same name appear in the list, but can accessed as one list
TimToady I'd like to be able to write /.../ ~~ my (...) and have the Match bound as a Capture, but I don't know how to write the my so that it gets tokens
pmichaud there are many things broken about that particular model, but it does manage to work. Essentially it's an ordered hash that understands numeric keys
(i.e., the order of keys is preserved.) 19:07
19:08 adc_Penner left
ruoso pmichaud, there's little magic in it... it does a numeric compare of strings... 19:08
19:08 adc_Penner joined
pmichaud I'm not advocating PHP's implementation, just pointing out that there's something that kinda works. 19:08
TimToady thing is, when I ask a match for its tokens, I *don't* want $0, $1, $2, etc 19:09
pmichaud (and that I've taken advantage of from time to time)
TimToady those are just names that happen to be numeric
avar pmichaud: php doesn't have hashes but rather key-value pair arrays, array_key_exists() is O(n) because of that 19:10
19:10 Lorn__ joined 19:11 pmurias joined
TimToady I don't really care how PHP does numeric indices. my point is that the parsing mindset fundamentally wants left-to-right, don't-throw-anything-away semantics, while the "extraction" mindset wants to throw all the dross out 19:11
and they can't both have list context :)
[particle] perl 6 should be allowed to have slow lookups if you want to preserve order
moritz_ TimToady: what's wrong with doing it with composition? 19:12
[particle] at least, slow lookups for order-preserved values
moritz_ TimToady: $/.splits being the left-to-right, everything else unchanged?
19:12 Jedai left
pmichaud actually, somehow the "left-to-right" mindset feels a lot like $/.pairs 19:13
TimToady well, that's one possible approach, but it doesn't solve the underlying problem (if there is one) with signatures
19:13 Jedai joined
ruoso TimToady, well... unless I'm missing something... I'd still argue to duplicate the named as positional... 19:13
in the cases you want that approach
pmichaud where $/.pairs could be different from %($/).pairs
pmurias when i wanted order for STD5_dump_match i just sorted the named fields of the Match 19:14
TimToady and rightly called it a mess
moritz_ pmurias: that code is neither nice nor efficient, I think ;)
pmurias moritz_: you mean the sorting part or the whole of STD5_dump_match? 19:15
PerlJam TimToady: what's the problem with signatures? mapping positional params with $0,$1, etc?
moritz_ pmurias: dunno. I didn't quite figure out how to separate the two 19:16
TimToady how do I write a signature to bind to a Match that gives me the tokens in order that they appeared? even *@_ doesn't give me the named args currently
19:16 adc_Penner left
ruoso TimToady, make the match return the named as if they were positionals also 19:16
then *@_ would contain everyone 19:17
pmichaud I'm curious by what we mean exactly by "give the tokens in the order that they appeared"
TimToady then does $0 contain the first parenthesized value or the matched string before it?
or is $0 the parens but $/[0] the string
pmurias moritz_: just assume that named are not positional?
19:03
TimToady
just assume that named are not positional?
19:03
TimToady
sorry 19:18
touchpad--
TimToady I like to see my name in print, but... :)
ruoso TimToady, i'd argue '$0 the parens but $/[0] the string'
pmichaud for example, with / [ (foo) baz <bar>? ]+ / what does "tokens in order appeared" mean? 19:19
PerlJam TimToady: I'd continue to go with historical precedent and have $0 and friends always contain parenthesized values.
moritz_ pmurias: in order in which they appeared in the source string
erm, pmichaud, sorry
pmichaud moritz_: so, we lose the "bar" label?
moritz_ pmichaud: we don't lose. We can still do $<bar>.
TimToady okay, now how do you get at the 3rd paren of a submatch without using the array subscripting form?
pmichaud you'd expect essentially [ 'foo', 'bar', 'foo', 'bar' ]?
TimToady well, I guess you use .<2> instead 19:20
I think you'd get Str objects for the "interstices"
that aren't bound to $0 or $<foo>
moritz_ TimToady: why not?
19:20 adc_Penner joined
pmichaud so [ match of (foo), 'baz', match of <bar>, match of (foo), 'baz', match of (foo), 'baz', match of <bar> ] 19:20
(assuming original string was "foo baz bar foo baz foo baz bar") 19:21
moritz_ pmichaud: yes, that's my vision
TimToady yes, where presumably each list element is sufficiently typed to tell what matched it
moritz_ pmichaud: (perhaps even with the whitespaces as ' ' in between)
pmichaud I'm thinking
ruoso TimToady, but why do you need the match to return the strings that were not captured?
TimToady certainly including the whitespace--I want them for my --p6 option to viv :) 19:22
19:22 xinming joined
pmichaud [ 0 => match of (foo), 'baz', bar => match of <bar>, 0 => match of (foo), 'baz', 0 => match of (foo), 'baz', bar => match of <bar> ] 19:22
19:22 Lorn left
TimToady ruoso: because I have a fundamental mistrust of algorithms that lose information and are hence not reversible 19:24
learned in the school of MAD
ruoso TimToady, right... but that could be a different method...
pmichaud either that, or the match objects need to know what they were matched as (which gets back to mncharity and allison requests for the same)
ruoso $/.tokenize
it doesn't need to be exposed in the $/.[0] syntax 19:25
PerlJam ruoso: or, $/.captures $/.tokens $/.etc :)
ruoso: you lose in optimization I think though.
ruoso well... if you need to store *all* the tokens... you loose anyway... 19:26
PerlJam ruoso: the trick is determining when that's needed or not. static scan for a particular method? Maybe the "keep all tokens" is a pragma that modifies the behavior of regex (and thus $/.tokens is only available when that pragma is there) 19:27
ruoso that looks sane
19:28 aindilis left
TimToady pragmas are usually insane 19:30
ruoso storing all tokens looks even more insane ;) 19:31
TimToady, but one way or another, the tokens doesn't need to be in $/.[0], but maybe only in $/.tokens[0] 19:32
19:33 aindilis joined
PerlJam TimToady: I could be insane too, but this discussion seems more "hard things easy" than "hard things possible" in some respects. 19:34
19:35 kst```` left
moritz_ PerlJam: only because things are hard with current semantics doesn't mean they have to stay hard 19:35
PerlJam moritz_: okay, how about more "hard things easy" than "hard things easier" then ? 19:36
moritz_ how about "simple things easier"? ;) 19:37
TimToady actually, I'm more worried about fundamental things broken
PerlJam I don't know ... keeping track of how every bit of text is parsed seems more "hard" than "simple" to me :)
19:38 Jedai left, Jedai joined
moritz_ from the implementor's point of view, yes 19:38
ruoso TimToady, right... as long as you don't say that we need to rewrite how capture works... ;)
moritz_ from the user's POV it's just walking a list, getting things in order - doesn't look too hard 19:39
TimToady it actually also ties into some of the things Morrie Siegel and I discuss every year at YAPC with regard to how P6 regexes aren't as good as SNOBOL :)
which is why I'm very interested in how matches bind to signatures 19:40
pmichaud TimToady: why isn't it a "normal" bind?
(naive question.)
ruoso by "normal", meaning: "named" as "named" and "positional" as "positional" 19:41
TimToady because I think it should be easier to deal with the tokens in order
pmichaud meaning: same as what we get if we do (...) := foo()
PerlJam Does prefix:<=> work on $/ ? =$/ ---> iterate the matched text in order
ruoso $/.tokens ?
pmichaud can dealing with tokens in order be done with a method (or iterator) on the match object?
TimToady this would be a more natural replacement for prefix binding, but would likely be postfix instead 19:42
something like / [ match some stuff] -> :(your bindings here) / give or take some syntax
ruoso I think it would more natural that the bindings reflected the captures... 19:43
pmichaud oh, I get it. You really are looking at Morrie's stuff :-)
TimToady which should presumably work similarly to doing the binding outside as well
yes, and I just don't want to make a bad decision right now that would make that difficult in the long run if it turns out pretty 19:44
ruoso Morrie?
pmichaud would "inorder" method on Match object be a bad decision that would make things difficult in long run?
TimToady it would force all such sigs to use some kind of unpacking-tree-nodes syntax, at worst, I suppose 19:45
but that could get pretty tiresome
PerlJam TimToady: there are still plenty of Unicode operators :) 19:46
TimToady Morris Siegel is a very smart fellow who wrote his dissertation on Snobol, and regularly (yearly) chats with Patrick and me about the philosophy of pattern matching. 19:47
PerlJam You know what I can never get used to? Almost all the interesting discussions here are just at the edge of my understanding :)
19:48 alester joined
pmichaud PerlJam: the same is true for me, and my understanding increases all of the time. I think that's what is meant by "bleeding edge". 19:48
TimToady he has a good eye for the discontinuities in our current design
pmichaud I'm not able to evaluate his proposals as well as TimToady, but a lot of them to me seem like replacing the current discontinuities with different ones. :-) :-) 19:49
moritz_ in the end, not everything is continuous
TimToady you have to filter what he says, sure, but his viewpoint is very different, and useful for that reason
pmichaud but they are indeed very useful, interesting, and sometimes lively chats
PerlJam In fact, I think most physicists believe the universe to be discrete :) 19:50
moritz_ (in physics actually the discontinuities are very interesting, and some of the are called "phase transitions")
19:50 bacek joined
PerlJam bears witness to Perl's phase transition. 19:50
TimToady the universe will be deflating in about 10 minutes
19:51 aindilis left
PerlJam Let me quote Mr. Siegel for a second: "selecting just the right assertion format sometimes is highly non-trivial and requires careful analysis, since the choice has a fundamental influence on the final logic" 19:52
we're firmly in non-trivial territory :)
TimToady anyway, the whole point of captures is to delay context determination till binding time, and if tokenizing is context-driven, we have to think about whether it's binding driven
19:53 insert_c1ins left
ruoso $/.token can be context-driven 19:53
19:53 aindilis joined
ruoso and can even be 'bvalue context' 19:53
$/.:tokens to make it look like other special bvalue methods... 19:54
and then you can bind it just as you would do with the match itself... but you keep the match safe from returning all the tokens directly 19:55
19:55 explorer left
TimToady well, if demand through $/ is what is actually driving the lazy match... 19:55
19:56 aindilis left
TimToady but I'm not sure we've reached that level of enlightenment yet 19:56
19:56 aindilis joined
ruoso it means that if you want all the tokens, you need to use $/.:tokens before consuming the match 19:56
TimToady what if someone passes you a signature that might or might not want to bind all the tokens? 19:57
pmurias don't we have :keepall for getting all the tokens?
ruoso TimToady, it seems to me that you want to add a third dimension in the capture...
a fourth, actully... considering we already have invocant, named and positional
TimToady maybe we should call them Elephants 19:58
ruoso or turtles
TimToady I keep trying to simplify them into lists with tagged elements 19:59
ruoso .oO( if that is simplifying... I just fear what it is to make more complex ) 20:00
TimToady phone # the universe is contracting now
PerlJam It seems to me that we have Signatures, Matches, and Captures. If you throw away the tokenizing info of a Match, that's much like a Capture. And Signatures and Captures are like mirror images of each other. Why would a Signature care about tokens at all? 20:06
(assuming you think of a Match has holding everything there is to know about what matched)
20:06 speckbot joined
PerlJam s/has/as/ 20:06
pugs_svn r22624 | pmurias++ | [mildew] fixed bug in sub {...} 20:07
20:07 alester left
pmurias ruoso: do you think mildew compiles t/pure_prototype_how.p6 correctly? 20:07
ruoso pmurias, almost... 20:08
postcircumfix:<( )> receives a capture object as first argument... and not the arguments directly
20:08 icwiener left 20:09 explorer joined
ruoso pmurias, and you're removing the "\n" of "1..1\n" for some reason 20:09
it wasn't supposed to be removed
pugs_svn r22625 | particle++ | [t] add three tests for import, currently failing in rakudo 20:10
pmurias how should Captures for postcircumfix:<( )> be created? 20:11
20:11 icwiener joined
pmurias $scope.lookup("Capture").FETCH.new(positional=>[...],named=>[...],invocant=>[...])? 20:12
hmm, the Capture.new could just take the capture it receives and replace the invocant with a shift()ed positional 20:13
ruoso pmurias, there's ¢SMOP__S1P__Capturize which is a preliminar implementation of that 20:14
ruoso later & 20:20
20:21 pmurias left 20:22 din joined 20:25 ab5tract joined 20:29 |Jedai| joined 20:39 ruoso left 20:46 Jedai left
pugs_svn r22626 | pmurias++ | [mildew] 20:47
r22626 | pmurias++ | plan in t/pure_prototype_how.p6 shouldn't have double newline
r22626 | pmurias++ | postcircumfix:<( )> receives a Capture.new_without_invocant(...) (found by ruoso++)
20:49 jferrero joined 20:50 explorer left 20:51 Lorn__ left 21:03 wknight8111 joined 21:07 adc_Penner left 21:08 rdice left 21:11 mncharity1 joined 21:12 ab5tract left, mncharity left 21:13 |Jedai| left, Jedai joined 21:20 jhorwitz left
pasteling "mncharity" at 98.216.110.149 pasted "isn't parsed by viv" (15 lines, 592B) at sial.org/pbot/32647 21:21
mncharity1 TimToady: the above code isn't parsed. a great many changes are sufficient to let it parse. so attempting to distil it down further wasn't making progress. it's a puzzle. if you'd like me to try harder, I will. 21:24
21:31 ryanc joined 21:34 icwiener left 21:38 xinming left 21:43 TJCRI left 21:50 xinming joined 21:53 iblechbot left 21:58 kst````` left, kst`````` joined 22:03 Jedai left, Jedai joined 22:04 Exodist left
mncharity1 btw, that was merely an fyi. I expect I can find some cheat to make it not a blocker, perhaps quite easily. 22:05
22:10 donaldh joined 22:12 donaldh left 22:20 hercynium_ joined 22:29 [particle]1 joined 22:35 mncharity1 left 22:48 ruoso joined 22:50 dduncan joined 23:00 AzureStone joined 23:11 pedrob left
TimToady heh: Can't create postfix:sym<i>: Identifier too long at (eval 498) line 1 23:23
23:23 hercynium_ left
TimToady I know what the problem is, and I have a workaround, but not a fix. 23:26
23:26 explorer joined
TimToady if you put each macro into its own block, then it won't keep adding to the previous language when it does mixins 23:27
the basic problem being that P5 doesn't support anonymous packages, so we generate new packages based on the old one
23:27 jferrero left
TimToady if you look at the directory tree under lex you'll see names like: 23:30
lex/STD/_prefix__S_500Bang/_prefix__S_501Plus/_prefix__S_502Plus/_prefix__S_503Plus/_prefix__S_504Tilde/_prefix__S_505Tilde/_prefix__S_506Minus/_prefix__S_507PlusPlus/_prefix__S_508MinusMinus
a mostly-good-enough fix would be to figure out which languages aren't used before they're extended, and coalesce 23:34
however, if there were an eval betweeen each of your definitions, it would have to remember all the intermediate languages so it would know what language to start with for the eval.
another partial fix would be to divorce the package name from the language pedigree 23:35
but then we still have to track the relationship, and the lex directories become more opaque
'course, there's a tremendous amount of duplicated info in lex/ right now, and compacting that down is probably my next trick after viv 23:37
23:37 jferrero joined
TimToady @tell mncharity see backlog for answer to your question 23:37
lambdabot Consider it noted.
23:38 Jedai left 23:39 Jedai joined
TimToady @tell mncharity starting at irclog.perlgeek.de/perl6/2008-10-15#i_623942 23:39
lambdabot Consider it noted.
23:43 PZt left
TimToady btw, generating all those new languages is why it parses so slow. It would also speed up if we suppress the intermediate language generation where it's unneeded 23:43
but correctness before performance 23:44
there's still oodles and gobs of room for optimization
maybe we really just want a syntax that defers language generation till later. much like we use prefix:sym<++> to name the rule that will later produce prefix:<++> 23:49
that would also let you use the current language's definition of prefix:<++> in the body 23:51
maybe prefix:export<++>
doesn't take effect till imported
and since a bunch of 'em are imported at once, need not generate a bunch of unused intermediate languages 23:52
23:53 explorer left
TimToady and the new language is named by a pedigree of uses, not a pedigree of macros 23:53
alternately, establish a rule that macros are only ever introduced at the end of the current block 23:55
then establish the convention of putting all your macro defs into a block at the top 23:56

Powered by Cro and the Raku® Programming Language.

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

Thank you!