Perl 6 - the future is here, just unevenly distributed

IRC log for #perl6, 2008-10-14

Perl 6 | Reference Documentation | Rakudo

| Channels | #perl6 index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:06 lichtkind_ joined #perl6
00:12 mncharity I note gimme5, given '3 || 4', doesn't seem to actually mention the op anywhere.
00:14 TimToady strange
00:40 jeja left #perl6
00:45 TimToady I think I need to fix the cycles differently to avoid losing operator info like sym
00:45 TimToady decommuting &
00:50 kst`` joined #perl6
00:57 mncharity ah, ok.
01:24 pugs_svn r22601 | putter++ | [elfish/STD_blue] Continuing to adapt IR constructors to gimme5.
01:30 ruoso hmm... s1p_array doesn't support push yet...
01:31 mncharity modulo circularity/op, some elf files are starting to look vaguely plausible.  current plan is: () get to elf self-compilation; () running STD_blue against STD.pm, teach elf to generate IR for it; () incrementally teach elf to run STD, piece by piece.
01:32 pugs_svn r22602 | ruoso++ | [smop] starting to implement multi... blocking on s1p_array.push
01:32 mncharity hi ruoso.  I've only the fuzziest idea what your current state is.  is there a summary somewhere?
01:34 ruoso mncharity, hi... the first page of the wiki explains it quite extensively
01:34 ruoso specially the ROADMAP and Changelog parts
01:35 mncharity thanks
01:35 ruoso mncharity, but there are some cool tests in the test/ directory
01:35 ruoso specially the .m0ld files
01:36 ruoso mncharity, one of my favorite tests is the test/35
01:37 mncharity looking...
01:37 ruoso that test demonstrates how SMOP implements lazy grep/map
01:38 wknight8111 joined #perl6
01:38 mncharity :)
01:39 ruoso we're actually very close of having enough runtime to comile src-s1p/P6Meta.pm to m0ld
01:39 mncharity re multi dispatch, any plans to write out the dispatcher in p6 first?  I'd love to have a reference copy.
01:39 ruoso well.. the dispatcher itself will be in m0ld probably...
01:40 ruoso unless pmurias manage to get mildew running more things quickly
01:40 ruoso which will then mean that we might have the sub dispatcher written in P6
01:40 ruoso mncharity, but the method dispatcher is already going to be written in P6 anyway
01:41 ruoso mncharity, it should be written in the src-s1p/P6Meta.pm class
01:41 ruoso which is the 'default' p6 HOW implementation
01:41 mncharity P6Meta interesting
01:42 ruoso and then there's src-s1p/Object.pm
01:42 ruoso our next major milestone is compiling both P6Meta and Object
01:42 ruoso which will mean that we've bootstrapped our type system
01:43 ruoso then it's just a matter of writing the built-in types in Perl 6
01:43 ruoso and the native types in the RI DSL
01:43 ruoso which is the final step before porting the actual compiler to smop
01:44 mncharity what are you parsing P6M and Obj with?
01:44 ruoso we aren't yet
01:44 ruoso we plan to parse it with STD
01:44 ruoso that's what mildew is about
01:45 ruoso actually, it should already be parseable by std...
01:47 ruoso hmm... it doesn't... it seems STD doesn't like pod yet
01:48 ruoso hmmm... ooops... it's actually my fault
01:48 mncharity re mildew, ah, ok.  sigh.  we've ~no developers, so we duplicate each others work too.  ah well.
01:49 ruoso mildew is turning STD parse tree (actually it's viv AST iirc) into m0ld
01:49 ruoso I'm not sure it's actually the same thing of STD_rgb
01:50 mncharity re it's viv, yes
01:51 * mncharity greps for STD_rgb, then, d'oh.
01:51 ruoso btw... STD does parse Object.pm (after some fixes I'll commit in a bit)
01:51 ruoso ;)
01:51 hercynium joined #perl6
01:53 mncharity STD _accepts_ Object.pm... ah, nm.  :)  there advantages to exploring two approaches to the same thing after all.
01:53 alester_ joined #perl6
01:56 mncharity re STD_rgb, viv is a tree walker and AST class creator.  STD_blue walks the same tree, but dispatches to functions identified by the node rule names (IRx1_FromAST).  so, similar.
01:57 ruoso mncharity, but targeting different runtimes... which mean... not really mergeable...
01:57 pugs_svn r22603 | ruoso++ | [smop] small fixes to src-s1p... both files are parseable by std now
01:57 ruoso for some reason STD accepts 'my List of Method @foo;' but not 'my List of Attribute @foo;'
01:58 ruoso std: my List of Method @foo;
01:58 p6eval std 22602: OUTPUT[parsed␤]
01:58 ruoso std: my List of Attribute @foo;
01:58 mncharity hmm.  if the runtime is affecting AST handling, that's probably a design problem.  even allowing the runtime to affect/infect the IR is problematic.
01:58 p6eval std 22602: OUTPUT[parse failure␤]
01:59 ruoso mncharity, well... the line of where it's really AST and where it's an OPTree
01:59 ruoso it's a very thin one
02:00 mncharity basically, once smopish is running subs, lexicals, package vars, temp, a few other things, adding a smopish backend to elf, to go with the current p5 and CL, should be a few days work.
02:00 ruoso mncharity, that's basically the plan... yes
02:00 ruoso mncharity, and eventually porting the compiler itself to smop
02:01 ruoso TimToady, any expected reason for std accepting 'my List of Method @foo' and not 'my List of Attribute @foo' ?
02:03 ruoso mncharity, anyway... there's a very important task we didn't start yet... which is writing "method dispatch()" in P6Meta.pm
02:03 ruoso "method dispatch()" is the method that implements method dispatch
02:03 * ruoso .oO( bootstrap is a curious thing, isn't it? )
02:04 mncharity re "the line of where it's really AST and where it's an OPTree", "it's a very thin one", eep.  I very much suggest not.  compiling p6 well, type inference, data flow, etc, is something to be done in p6, on a backend-neutral intermediate representation.
02:04 mncharity re "bootstrap is a curious thing", ! :) !
02:04 mncharity yeah, despite all the crud cruft and slogging, I truly love it.
02:05 ruoso I mean... we all aim to a backend-neutral IR... but I'm still not sure we're going to get it
02:05 mncharity could you elaborate?  I can't really imagine why not...
02:06 ruoso hmmm... I have a reason to think that, I know I do... it's somewhere in my brain...
02:07 * ruoso EASLEEP
02:07 mncharity even if we end up with several IR's, with different properties (immutable, tree swizzling, etc), well, that's what multis are for.
02:08 mncharity re sleep, yeah.  end of day.
02:08 ruoso well.. it probably just mean that I'm not very much worried about the AST being trully abstract...
02:08 ruoso as long as it runs...
02:09 ruoso I think my concern is really about having the separation of compilation and runtime
02:09 ruoso but I'm too asleep to think...
02:09 ruoso later &
02:09 * ruoso zZzZzZzZ
02:09 mncharity yeah.  an advantage of the smopish close-to-the-metal approach the compiler can afford to be dumber.  CL requires a bit more smarts.  and p5 vastly more.
02:10 mncharity g'night rouso
02:10 mncharity good night all &
02:12 kst`` joined #perl6
02:30 agentzh left #perl6
02:55 agentzh joined #perl6
03:01 elmex joined #perl6
03:04 * partclCoke yawns
03:06 ab5tract joined #perl6
03:08 partclCoke left #perl6
03:20 kst`` joined #perl6
03:20 coke joined #perl6
03:34 BinGOs joined #perl6
03:58 z80ASM joined #perl6
04:08 z80ASM joined #perl6
04:11 alester_ joined #perl6
04:47 kst`` joined #perl6
06:00 pugs_svn r22604 | lwall++ | [STD] revise cycle removal to preserve op fields other than PRE and POST
06:00 kst`` joined #perl6
06:00 Psyche^ joined #perl6
06:19 jferrero joined #perl6
06:21 adc_Penner joined #perl6
06:36 mallory_ joined #perl6
06:38 BinGOs joined #perl6
06:39 ashizawa joined #perl6
06:54 pmurias_ joined #perl6
07:05 pmurias_ ruoso: actually it should be possible to use (a slightly modified) mildew IR to target other backends
07:11 pugs_svn r22605 | pmurias++ | [mildew] unfinished infix:<=> handling, t/pure_prototype.t showing how far are we from defining a method
07:12 pmurias_ ruoso: have you seen mildew --desugar?
07:24 kst`` joined #perl6
07:26 mallory_ hi, agentzh
07:29 agentzh mallory_: hiya
07:29 mallory_ :D
07:30 agentzh just a bit surprised to see you here :P
07:32 kanru joined #perl6
07:35 sri_work joined #perl6
07:45 cosimo joined #perl6
07:46 mallory_ just walk
07:48 zamolxes joined #perl6
07:50 iblechbot joined #perl6
07:51 adc_Penner2 joined #perl6
07:57 [particle] joined #perl6
07:58 He||Raiser|CFR- joined #perl6
07:59 He||Raiser|CFR- left #perl6
08:16 ejs joined #perl6
08:29 tomyan joined #perl6
08:43 AzureStone joined #perl6
08:46 ashizawa joined #perl6
08:46 agentzh joined #perl6
08:46 AzureStone_ joined #perl6
08:46 xinming_ joined #perl6
08:46 ingy joined #perl6
08:46 krunen joined #perl6
08:46 ilogger2 joined #perl6
08:46 Helios- joined #perl6
08:46 awwaiid joined #perl6
08:49 masak joined #perl6
08:50 mallory__ joined #perl6
08:55 pjcj joined #perl6
09:01 schmalbe joined #perl6
09:04 szbalint joined #perl6
09:04 masak joined #perl6
09:04 jferrero joined #perl6
09:04 p6eval joined #perl6
09:04 Southen_ joined #perl6
09:04 pmichaud joined #perl6
09:04 gbacon joined #perl6
09:04 kcwu joined #perl6
09:04 rhr joined #perl6
09:04 bennymac1 joined #perl6
09:04 nothingmuch joined #perl6
09:05 nnunley joined #perl6
09:09 kst``` joined #perl6
09:09 bjakb joined #perl6
09:31 Maghnus joined #perl6
09:42 ruoso pmurias, Can't locate object method "term__S_386identifier" via package "STD" at ../../src/perl6/STD.pm line 1002.
09:42 ruoso pmurias, does that mean I'm missing compiling something?
09:56 bacek joined #perl6
10:07 sri_work_ joined #perl6
10:13 [particle] joined #perl6
10:21 Khisanth joined #perl6
10:39 kst``` joined #perl6
10:43 bacek joined #perl6
11:07 bacek joined #perl6
11:07 rdice joined #perl6
11:12 ruoso_ joined #perl6
11:15 araujo joined #perl6
11:26 rdice_ joined #perl6
11:49 ruoso_ if a multi can be used anywhere a sub can be used, that means it should implement postcircumfix:<( )>
11:49 ruoso_ but considering lexical variants
11:50 ruoso_ the implementation of that specific multi is not aware of all the variants available... it's only aware of the ones declared in the same scope
11:50 ruoso_ this might mean:
11:50 ruoso_ 1) that it goes looking in the CALLER for other variants
11:52 ruoso_ 2) that calling postcircumfix:<( )> directly on the object means looking for variants only in that multi object ignoring all the lexical variants
11:52 ruoso_ 3) that multi is not really a Code, but just a container, and therefore, it doesn't implement postcircumfix:<( )> at all
11:53 ruoso_ I should say that I'm assuming the (multi)sub dispatch is something external to each sub....
12:05 ruoso_ I just realized that Multi is not even a type...
12:05 ruoso_ hmmm...
12:07 kst``` joined #perl6
12:09 ruoso_ bbiab &
12:09 ruoso_ left #perl6
12:12 ruoso__ joined #perl6
12:13 Bzek joined #perl6
12:16 zamolxes joined #perl6
12:25 insert_c1ins joined #perl6
12:25 ruoso_ I think I'll assume a multi is just a container... let's see if #parrot folks have something to say about it...
12:31 aindilis joined #perl6
12:52 iblechbot joined #perl6
12:55 alester joined #perl6
12:59 Lorn joined #perl6
13:14 * ruoso_ later &
13:14 alanhaggai joined #Perl6
13:18 pmurias_ joined #perl6
13:19 pmurias_ @tell ruoso you should recompile STD had exactly the same error when i used an old one and rm -fr lex
13:19 lambdabot Consider it noted.
13:34 Pzt joined #perl6
13:40 kst``` joined #perl6
13:58 TJCRI joined #perl6
14:03 rakudo_svn r31946 | pmichaud++ | [rakudo]: spectest-progress.csv update: 204 files, 4380 passing tests
14:03 TJCRI joined #perl6
14:03 sri_work joined #perl6
14:03 rakudo_svn r31947 | pmichaud++ | [rakudo]: Don't use leading '::' for storing generic type lexicals.
14:03 rakudo_svn r31947 | pmichaud++ | This gets us closer to supporting interpolated namespaces.
14:31 cognominal joined #perl6
14:47 silug joined #perl6
14:58 jferrero joined #perl6
14:59 [particle]1 joined #perl6
15:09 rakudo_svn r31948 | pmichaud++ | [rakudo]:  Eliminate <generic_binder> and remove '::' as a <sigil>.
15:09 [particle]2 joined #perl6
15:12 pedrob joined #perl6
15:21 kst``` joined #perl6
15:39 silug joined #perl6
16:00 armagad joined #perl6
16:04 hercynium joined #perl6
16:10 jan_ joined #perl6
16:20 jhorwitz joined #perl6
16:23 pedrob joined #perl6
16:24 pyrimidine joined #perl6
16:24 justatheory joined #perl6
16:26 kanru joined #perl6
16:34 alanhaggai joined #Perl6
16:38 alester joined #perl6
16:40 nothingmuch joined #perl6
16:43 OsamaK joined #perl6
16:43 pedrob joined #perl6
16:45 kane_ joined #perl6
16:49 TimToady so should it be ceil or ceiling?  or ⌈...⌉  :)
16:51 moritz_ the answer is usually "yes" ;)
16:51 TimToady pugs implements the first two o_O
16:56 [particle]2 ceiling, please
16:56 [particle]2 we don't say floo for floor
16:59 pmurias_ joined #perl6
17:03 TimToady but we say abs for absolute and sin for sine
17:04 TimToady sin for sine is completely as(sin)ine
17:05 TimToady I can kinda understand abs for absolute though
17:05 adc_Penner joined #perl6
17:05 moritz_ and 'sin' is what you always use in math anyway
17:05 TimToady but the fact is that mathematicians write "sin"
17:06 TimToady but not "ceil"
17:06 TimToady they use ⌈...⌉
17:06 TimToady 'course we've made it impossible to use |$x|    :)
17:07 moritz_ I did a quick search with google code search for \bceil\b and \bceiling\b
17:07 moritz_ ceiling: 121k
17:07 TimToady well, given that it's ceil in C
17:08 moritz_ ceil: 256k
17:08 TimToady can you tell what languages use ceiling?
17:08 TimToady or is it all in comments?  :)
17:09 moritz_ it seems most is user defined, or in weird programming langues that I don't recognize ;)
17:09 moritz_ public class Ceiling extends NumericFunction {
17:09 TimToady heh
17:10 moritz_ that might be over-engineering - but of couse I don't know that
17:10 moritz_ *course
17:11 TimToady well, I think huffman probably calls for ceiling
17:11 ruoso joined #perl6
17:13 TimToady and looking at how it's used in t/, I'm sure of it
17:13 TimToady push @p, $x unless grep { $x % $_ == 0 }, 2..ceil sqrt $x;
17:13 ZuLuuuuuu joined #perl6
17:14 ruoso TimToady, is it really impossible to catch |$x| as different from |$x ?
17:14 lambdabot ruoso: You have 1 new message. '/msg lambdabot @messages' to read it.
17:14 TimToady ceil sqrt sounds like some kind of sea creature
17:14 TimToady It's possible with ferocious backtracking
17:14 TimToady but we don't do ferocious backtracking
17:15 ruoso hmm... ok...
17:15 ruoso (we could always change '|' to something not used by math)
17:15 TimToady |$x + $y + $z|
17:15 moritz_ 2+|$x|+3 # a junction, or a sum?
17:15 TimToady could have a +|...| circumfix, I suppose
17:16 TimToady and a -|...| circumfix
17:16 moritz_ I don't think it's a very good idea
17:16 TimToady me too
17:17 [particle] so leave it to someone else to do it :)
17:17 TimToady plus we've already taught mathematicians to write abs when talking to computers :)
17:17 ruoso heh
17:17 [particle] abs-minded professors?
17:17 * TimToady cringes
17:18 ruoso pmurias, mildew still fail to parse test-mildew/pure_...
17:18 ruoso pmurias, it gives me another error... but it still fails...
17:18 TimToady it might be that capture interpolation is too short, huffmanwize
17:20 pmurias_ ruoso: maybe, i'm the one with the old copy, checking...
17:20 pmurias_ ruoso: did you rm -fr v6/mildew/lex/
17:20 ruoso pmurias, yes
17:20 Juerd_ joined #perl6
17:20 ruoso pmurias_, kill your ghost, please ;)
17:21 pmurias_ the irssi is run on a machine i don't can't ssh to and i'll have access to in ~2weeks
17:22 ruoso pmurias_, you can always /msg NickServ ghost
17:22 pmurias_ hmm?
17:22 ruoso pmurias_, /msg NickServ ghost pmurias yourpasswd
17:23 [particle] that will remove pmurias, then you can /nick pmurias
17:23 [particle] and /msg nickserv identify pmurias password
17:23 ruoso [particle], hi... have you seen my comments on multi?
17:23 pmurias_ joined #perl6
17:24 [particle] ruoso: not anything since last wednesday
17:24 ruoso http://irclog.perlgeek.de/​perl6/2008-10-14#i_620509
17:24 lambdabot Title: IRC log for #perl6, 2008-10-14
17:24 ruoso I'd really appreciate some thoughts on that...
17:25 pmurias ruoso: the one in mildew/t is the one that actually parses the one in test-mildew is the intenended test
17:25 lambdabot pmurias: You have 3 new messages. '/msg lambdabot @messages' to read them.
17:25 ruoso pmurias, oh... ok...
17:25 [particle] ruoso: aren't all subs multis unless declared only?
17:25 ZuLuuuuuu left #perl6
17:26 pmurias [particle]: no
17:26 * [particle] rereads the spec
17:26 apeiron joined #perl6
17:26 ruoso [particle], but it doesn't change the problem
17:26 ruoso [particle], either way you have lexically-declared variants...
17:27 pugs_svn r22606 | lwall++ | [S29] settle on "ceiling"
17:28 * ruoso wonders if some module could define |$x| to be a syntax for abs() and redefine junctions and capture interpolation to something else...
17:28 pmurias ruoso: the way I view it a lexical variant creates a new multi
17:28 ruoso pmurias, yes... I see that way too... but the problem is, what does $multi.postcircumfix:<( )> do?
17:28 pmurias ruoso: |$x| isn't particularly good syntax
17:29 ruoso for general code, yes... but for some more specific use, maybe not
17:29 pmurias it takes into account all the variants in place when $multi = &multi happened
17:30 ruoso pmurias, that would mean creating a clone for the multi at every new re-declaration
17:31 ruoso (sort of, but the consequence would be the same)
17:33 pmurias ruoso: yes, but it's better for the creation to be expensive than for the call
17:33 ruoso well... I was considering that as a possible optimization...
17:34 ruoso I mean...
17:34 ruoso considering sub dispatch fallback to the package lookup
17:34 ruoso or even CANDO
17:34 pmurias does it?
17:34 ruoso yes... sub dispatch is 'no strict'
17:34 pmurias no
17:35 ruoso pugs: &Foo::bar := sub { 1 }; module Foo { sub baz { bar() } }; say Foo::baz();
17:35 p6eval pugs: OUTPUT[1␤]
17:36 ejs joined #perl6
17:37 pmurias ruoso: S02:2824
17:38 ruoso pmurias, I'm not sure I see what you mean
17:39 jferrero joined #perl6
17:39 * [particle] tries to follow, but is on the phone...
17:39 ruoso pmurias, "The postdeclaration may be in any lexical or **package** scope"
17:40 pmurias they are checked at compile time
17:41 ruoso pugs: module Foo { sub baz { bar() } }; say Foo::baz(); INIT { &Foo::bar := sub { 1 } }
17:41 p6eval pugs: OUTPUT[1␤]
17:41 pmurias S02:2831
17:43 ruoso hmmm... ok... I think I see what you mean...
17:43 ruoso but...
17:43 ruoso does that mean that no new variants can be added in runtime to a pre-declared proto?
17:43 ruoso I would doubt that
17:44 ruoso oh... wait... but in that case, it would be to an already known multi object..
17:44 pmurias if the multi was a package scoped one you could propably change it
17:45 ruoso if Foo::bar() is a multi, what happens if you &Foo::bar := somethingelse()?
17:46 ruoso does it add a variant?
17:46 ruoso or does it replace the entire multi with all variants by a new thing?
17:48 pedrob joined #perl6
17:48 pmurias i think it replaces the entire multi
17:49 kst``` joined #perl6
17:53 ruoso so it seems it needs to be late-dispatched anyway...
17:54 ruoso and the cloning doesn't seem to solve the problem
17:55 pedrob_ joined #perl6
17:55 pmurias what's the problem btw ;)
17:56 ruoso the problem is: 1) Multi isa Code? 2) .() looks in the CALLER?
18:02 mncharity joined #perl6
18:02 mncharity @tell pmurias re mildew as duplication (last night), I was wrong.  eg, elf doesn'
18:02 lambdabot Consider it noted.
18:03 pmurias 2) .() looking in CALLER seems too magical for me, and i think Multi isa Code as treating it an object instead of a bunch of variants allows you to do fancy stuff with it such as using it as a callback
18:03 lambdabot pmurias: You have 1 new message. '/msg lambdabot @messages' to read it.
18:03 pmurias mncharity: hi
18:03 mncharity t duplicate rakudo.  focus on "usable and p6" vs "solid foundation".  distinct impacts on language dev, different pragmatics.
18:03 mncharity hi pmurias.  :)
18:04 ruoso pmurias, so you think .() on the multi object causes an invocation on the variants inside that multi object only?
18:04 pmurias yes
18:04 mncharity potential to share ideas, code, blur together.  similarly, mildew compliments elf's currently narrow focus on getting to bootstrap.
18:04 pmurias ruoso: but i might not see the big picture
18:05 pmurias mncharity: mildew tries to express everything in terms of method call
18:05 pmurias * calls
18:05 mncharity witness yesterday's(?) kludgery to force temp() back to being a scope_declarator, because updating to current spec isn't critical path.
18:05 ruoso pmurias, in my head it's one of 1) traverse CALLER, 2) call only this variants or 3) doesn't implement .() at all
18:06 ruoso I'd vote for 3 or 2
18:06 mncharity re calls, yes.  no method calls existed when elf's version was started, and until bootstrap and macros, doing something more plausible doesn't seem critical path.
18:06 mncharity so, I was wrong to characterize it as duplicated effort.
18:07 mncharity back later.  err, or perhaps more likely tomorrow.  cheers.
18:07 pmurias mncharity: could common lisp handle doing everything in an OO way?
18:07 mncharity really have to run.
18:07 pmurias ok
18:08 TimToady what do multis have to do with caller?
18:08 TimToady it's all lexical
18:09 ruoso TimToady, the question is if Multi isa Code in the first place...
18:09 mncharity briefly, there are CL instance-based oo impls with good performance.  hoping to perhaps take ideas/code from one of them.  but, different backends, different properties.
18:09 TimToady define Multi
18:09 mncharity cheers. &
18:09 ruoso TimToady, the stuff that holds the variants
18:09 ruoso where each variant is a code object
18:10 TimToady we can have &code objects that represent multiple candidates
18:10 ruoso yes... but it can't represent all the candidates
18:11 TimToady sounds like Multi is just a Code that does a null .assuming :)
18:11 ruoso the problem is really about having several &code objects that represent different multiple candidates
18:12 ruoso and what happens when you &code.() on one of that objects
18:12 TimToady what do you think &foo.assuming() should return, besides all the candidates?
18:12 moritz_ or maybe &code is really a junction of multis?
18:12 ruoso itself?
18:12 schmalbe joined #perl6
18:13 pmurias buying food&
18:13 ruoso moritz_, that's not the issue...
18:13 ruoso the issue is the fact that we have several "variant container"s
18:13 TimToady any &code represents one or more candidates
18:14 ruoso but the sub dispatch need to find all declarations of &code in the lexical scope
18:14 ruoso which mean several objects holding each one several variants
18:14 ruoso the question is what happen when you &code.() on one of those specific objects...
18:14 TimToady well, the compiler finds the lexical variants, not the dispatch
18:15 TimToady the dispatch just needs to look at the available candidates in &code produced by the compiler and call one of them
18:15 ruoso TimToady, can't a new variant for infix:<+> be added at runtime?
18:16 ruoso doesn't it affects the code globally?
18:16 TimToady yes, in which case you need to recalculate, but I think of that as recaching, not as dispatch
18:16 ruoso right... so let's leave caching aside by now
18:16 TimToady it affects anything that can see it lexically, where global is "most lexical"
18:16 TimToady s/most/outermost/
18:18 pmurias TimToady: is there a way to prevent adding a new variant at runtime
18:18 pmurias ?
18:18 TimToady don't let your candidate list generate from any namespaces that can be changed at run time
18:19 TimToady if you put a proto in your outermost lexical, it hides anything outside it
18:19 ruoso hmmm
18:19 rdice_ joined #perl6
18:19 moritz_ a proto in an *outer* scope hides something?
18:20 * moritz_ finds that confusing
18:20 ruoso moritz_, hides the outer outer scope
18:20 pmurias TimToady: and eval("multi foo {...}")?
18:20 TimToady an "only" sub also hides anything outside of it
18:20 TimToady without a scope qualifier, it goes into your current package
18:21 TimToady which gets looked at somewhere just outside your outermost ordinary lexical scope, I thing
18:21 TimToady *think
18:22 ruoso TimToady, I'm assuming the dispatcher is the one that looks in the package
18:22 ruoso TimToady, but pmurias pointed that pugs is wrong about being 'no strict' on the sub names...
18:23 TimToady so, outer scopes go something like PROCESS < GLOBAL < prelude-lexical < package < file-lexical < block-lexicals, give or take
18:23 ruoso I still see that as two different axes
18:24 TimToady which axis is $foo on?
18:24 ruoso ordinary lexical scope, which ends in the prelude-lexical
18:24 TimToady which includes package
18:25 ruoso not really...
18:25 TimToady if your current package includes $foo, you see it
18:25 TimToady whether or not it was declared with "our"
18:25 ruoso because 'our $foo' creates a local bind to $package::foo
18:26 ruoso TimToady, which is the other way to declare $foo, besides 'our $foo'?
18:26 ruoso (and besides my $foo also, of course)
18:26 TimToady package variables don't need to be declared
18:26 TimToady $::foo = 42 is enough
18:26 ruoso but then you need to access them through the package, don't you?
18:27 ruoso and that's a different lookup
18:27 abz_ joined #perl6
18:27 TimToady the current package is implicit
18:27 PerlJam wait a second ... you still get a warning with stricture, yes?
18:27 TimToady but yes, $foo as an rvlaue fails under strict
18:27 PerlJam ah. ok
18:28 * PerlJam goes back to lurking
18:28 ruoso so... {package Foo; $bar = 1} is valid...
18:28 TimToady but if foo() doesn't call through the package, there's no way to override prelude at run time with a multi
18:28 TimToady since all lexical scopes freeze after compilation
18:29 ruoso TimToady, that's the part of sub dispatch being 'no strict'... maybe S02 is wrong...
18:29 * ruoso actually meant that as a question... is {package Foo; $bar = 1} valid?
18:29 TimToady if prelude defines a proto multi, then you can't see any multi of that name in GLOBAL
18:30 TimToady under no strict it's valid
18:30 pedrob joined #perl6
18:30 TimToady but $::bar = 1 is probably better style in Perl 6
18:30 ruoso TimToady, right... so it falls back to package lookup under 'no strict'
18:31 ruoso or "our $bar = 1'
18:31 ruoso which is probably even better
18:31 TimToady but that can have ramifications if there are other packages in scope
18:31 TimToady and those ramifications may be good or bad
18:31 TimToady so yes, "probably" :)
18:32 ruoso that's the part of "under no strict, it *falls back* to the package"
18:32 ruoso which means that it will only lookup in the package if no strict *and* if no lexical is found
18:33 ruoso TimToady, but that brings us back to the same problem...
18:33 TimToady whereas &foo is looked up in the order I listed above, more or less
18:34 ruoso right... I just try to keep my mind strict...
18:34 ruoso 'no strict' will be handled later...
18:35 ruoso package Foo { proto foo; package Bar { my multi foo (Int $a) {1} } }
18:36 silug joined #perl6
18:36 ruoso TimToady, the above example shows the issue I'm trying to address...
18:36 ruoso the lexical declaration 'my multi foo' needs to be stored somewhere different from the outer 'proto foo'
18:37 ruoso because it's lexical
18:37 ruoso unless I'm just crazy and that is simply not supporte
18:37 TimToady probably proto should be limited to lexical scope
18:38 ruoso TimToady, that meaning the above example is not valid?
18:39 TimToady well "proto foo;" by itself is illegal syntax
18:39 TimToady regardless of whether we decide to require "my"
18:40 TimToady and if you have "proto foo () {...}" then the multi would be an inconsistent signature
18:40 TimToady a bare "my proto foo {...}" would merely hide any outer foo without constraining the sig
18:44 * ruoso confused...
18:45 ruoso package Foo { proto sub foo ($a) {...}; package Bar { my multi foo (Int $a) {...} } }
18:45 ruoso TimToady, the above example seems more on-the-point...
18:47 TimToady that looks fine in the sigs, since Int is more restrictive
18:47 ruoso right... but where is the inner variant stored?
18:47 TimToady but as I say, we might require "my" on the proto to prevent run-time mods
18:48 TimToady either that, or the compiler can't actually rely on a proto in a package to mean anything
18:48 TimToady so it might as well not be there
18:48 TimToady the main point of a proto is to tell the compiler what it can assume for optimization
18:48 ruoso right... let me try to be even more specific...
18:48 TimToady otherwise the name hiding can be done with an "only" sub
18:49 ruoso package Foo { my multi foo (Str $a) {...}; package Bar { my multi foo (Int $a) {...} } }
18:49 TimToady illegal
18:49 ruoso oh... right...
18:49 ruoso so there isn't lexically-scoped variants for a multi
18:50 TimToady oh, sorry
18:50 TimToady misread
18:50 TimToady that's fine
18:50 TimToady and yes, those would be considered both viable candidates
18:51 TimToady and they compete on equal terms
18:51 ruoso but on the outer scope, only the outer declaration is seen
18:51 TimToady true
18:51 ruoso rigth...
18:51 ruoso that means we have two different storage for the variants
18:51 TimToady yes, &foo means two different things
18:52 ruoso what does it mean in the inner scope?
18:52 TimToady it means both candidates are used if you call foo($x)
18:52 ruoso that's sub dispatch
18:52 TimToady multi dispatch is sub dispatch
18:52 ruoso yes yes...
18:52 ruoso but I mean...
18:53 ruoso foo(); and &foo.() would mean different things?
18:53 TimToady no
18:53 hercynium_ joined #perl6
18:54 ruoso so postcircumfix:<( )> needs to look in the caller scope for the other available variants
18:55 TimToady there is no "other", either the object knows it is dealing with more than one candidate, or it is dealing with only one candidate
18:55 ruoso TimToady, so it implicitly references the outer multi from inside it?
18:55 TimToady the reason we have "only" subs is so that at least some &foo can know they have only one candidate at compile time
18:56 TimToady &foo is inside neither multi
18:57 TimToady if you will, &foo is the only sub that delegates to all multis of the same name that are visible
18:58 TimToady and if there is only one candidate, it can be coelsced with the the only at compile time
18:58 TimToady s/one/one possible/
18:58 TimToady *coalesced
18:59 TimToady but &foo is the "short name" abstraction, basically, and it might or might not represent multiple actual Code objects
19:00 ruoso that way &foo.() on a multi is undetermined
19:00 ruoso ?
19:01 TimToady or maybe &foo is the Code object, and there are multiple Sub objects.  not picky about the names
19:01 TimToady undetermined?
19:01 azawawi joined #perl6
19:01 TimToady &foo.() is the same as foo()
19:01 azawawi rakudo: say "ping"
19:01 p6eval rakudo 31953: OUTPUT[ping␤]
19:02 ruoso what do you mean by " it might or might not represent multiple actual Code objects"?
19:02 TimToady once you've use .() it must find a single code object and call it
19:03 TimToady *used
19:03 ruoso right... but bare &foo ?
19:03 TimToady bare &foo represents all candidates of that short name (unless otherwise bound)
19:04 TimToady &foo := &bar.assuming(42) can put a different candidate list into &foo
19:05 pmurias all candidates as seen from the lexical scopes where it appears?
19:05 ruoso or all candidates including the ones that can be added at run-time in the package?
19:06 TimToady if the package names are visible
19:06 TimToady which depends on where the proto (if any) is declared
19:06 ruoso just to make clear... that is the key point to determine if the multi sub dispatch belongs inside the sub object or outside of it...
19:06 TimToady which is why I put the package inside prelude
19:07 TimToady all Code objects respond to .(), but some of them must dispatch to a shorter list of candidates.
19:08 kst``` joined #perl6
19:08 TimToady whether a Code object is singular or plural is hidden info
19:08 ruoso so the innermost declaration of a name should respond to .() including all the outermost candidates...
19:09 TimToady yes, and it would be good to include the innermost candidate as well :)
19:09 ruoso :) heh
19:09 ruoso ok...
19:10 ruoso so the dispatch belongs inside the sub, not outside...
19:10 TimToady which probably means that the infrastructure uses some hidden .invoke rather than overloading .()
19:11 ruoso TimToady, it actually overloading .() just fits
19:11 TimToady fine if it works
19:11 ruoso s/it//
19:11 ruoso and the invocation only see the innermost declaration
19:12 TimToady whenever I get confused about roles I take it as a sign that I should let the implementations fight it out
19:12 TimToady &foo is intended to be a simplifying abstraction, yes
19:12 TimToady it represents the current overloading
19:12 ruoso ohwkay
19:13 TimToady lexically current
19:13 TimToady where that might or might not extend out through a run-time modifiable package
19:13 ruoso so my plan is...
19:14 TimToady in which case the cache has to be invalidatable
19:14 ruoso every multi declaration creates a Multi object that holds all the candidates declared in that level
19:15 ruoso an additional "our multi foo" adds a candidate to an existing multi (or creates the global one if non-existant)
19:15 TimToady note also that multies can be postdeclared in a scope
19:15 ruoso TimToady, which then mean adding more candidates to the same Multi object
19:16 TimToady yes
19:16 TimToady and all the &foo in that block refer to the same Multi
19:16 ruoso yes
19:16 ruoso an inner Multi holds a reference to the lexical scope in which it was declared, giving a path to access the outer Multi object
19:16 TimToady but also note that postdeclarations can come from outer scopes as well :)
19:17 ruoso TimToady, the key is keeping late-dispatch
19:17 ruoso and having cache as optimization
19:17 TimToady right
19:18 TimToady or, if not run-time late, at least CHECK-time late
19:18 ruoso 'our multi foo' in an inner scope means adding a local alias to the global Multi object that now has one more candidate
19:18 TimToady and run-time late if packages are involved
19:18 ruoso hmm...
19:18 ruoso actually...
19:18 ruoso not really
19:19 ruoso (not what you've said, but what I've said
19:19 TimToady biab &
19:20 ruoso 'our multi foo' in an inner scope means creating an empty Multi object, and the global Multi object would have one more candidate
19:21 ruoso anyway... I think everything is settled now..
19:22 pugs_svn r22607 | particle++ | [t] add more 'is export()' trait tests
19:23 rakudo_svn r31954 | particle++ | [rakudo] add 'infix:=:=' and 'infix:!=:=' ops
19:23 pugs_svn r22608 | pmurias++ | [mildew] sigils are part of the variable's names
19:24 rakudo_svn r31955 | particle++ | [rakudo] refactor 'is export()' trait code to prepare for handling taglists
19:24 pmurias ruoso: does mildew --desugar --file t/pure_prototype_how.p6 work for you?
19:25 ruoso yes... the output doesn't make much sense...
19:26 cathyal joined #perl6
19:28 bacek joined #perl6
19:31 pmurias ruoso: --desugar prints out the IR before it is broken down into opcodes
19:33 pugs_svn r22609 | pmurias++ | [mildew] fixed my, --desugar uses mold {...} instead of {...}
19:34 pmichaud std:  sub foo() is export(:DEFAULT :others) { ... }
19:34 p6eval std 22608: OUTPUT[parsed␤]
19:35 pmurias ruoso: it doesn't make sense as in not being clear what it is, containing bugs, or t/pure_prototype_how.p6 not making sense yet (as mildew can't handle some stuff yet)
19:44 pugs_svn r22610 | pmurias++ | [mildew] infix:<=> with a method call on the left side
19:47 pmurias TimToady: STD parses anonymous methods incorrectly
19:47 pmichaud std:  3 + :a :b
19:47 p6eval std 22610: OUTPUT[parsed␤]
19:55 pugs_svn r22611 | moritz++ | [t/spec] clarified where.t a bit, as suggested by TimToady++
19:56 pugs_svn r22612 | pmurias++ | [mildew] anonymous subroutines
19:58 greatflamingfoo joined #perl6
19:58 azawawi how can i autoflush $*OUT for prints in p6?
19:59 moritz_ did you look in S16? (I have no clue)
20:00 azawawi i only found a quick reference on it in draft S28
20:01 pugs_svn r22613 | moritz++ | [t/spec] some unfudging for rakudo, [particle]++
20:06 azawawi moritz_: 'print "your choice:"; my $foo = =$*IN' does not show anything until you press enter...
20:06 moritz_ azawawi: which implementation?
20:07 azawawi moritz: rakudo & pugs
20:08 azawawi moritz_: and =<> returns -1 on perl6 without waiting for input on rakudo
20:08 moritz_ azawawi: yes, it's known to be b0rked :(
20:13 ab5tract joined #perl6
20:15 [particle]1 joined #perl6
20:16 humo85 joined #perl6
20:17 humo85 left #perl6
20:20 justatheory joined #perl6
20:20 TimToady pmurias: I believe I've found the problem--EXPR was reducing till @termstack had 1 term rather than until @opstack had 0 ops, so it never reduced unaries that were not otherwise forced
20:20 TimToady testing
20:24 pugs_svn r22614 | lwall++ | [STD] EXPR quit reducing too soon on unaries
20:26 pugs_svn r22615 | moritz++ | [src/perl6/Makefile] don't rm -rf lex/ on every 'make'.
20:26 pugs_svn r22615 | moritz++ | Use /usr/local/bin/perl in Makefile, because that's what all the scripts use
20:26 pugs_svn r22615 | moritz++ | anyway.
20:27 _Jedai_ joined #perl6
20:27 Torment joined #perl6
20:28 zamolxes joined #perl6
20:31 [particle] joined #perl6
20:32 jferrero joined #perl6
20:50 meppl joined #perl6
21:06 jferrero joined #perl6
21:12 spx2 joined #perl6
21:12 spx2 :)
21:24 kst``` joined #perl6
21:52 [particle]1 joined #perl6
22:03 wknight8111 joined #perl6
22:26 ruoso joined #perl6
22:55 meppl good night
23:03 jrockway joined #perl6
23:06 literal joined #perl6
23:16 explorer__ joined #perl6
23:24 dolmen joined #perl6
23:30 Limbic_Region joined #perl6
23:37 PZt joined #perl6
23:39 jrockway joined #perl6
23:46 kst``` joined #perl6

| Channels | #perl6 index | Today | | Search | Google Search | Plain-Text | summary

Perl 6 | Reference Documentation | Rakudo