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.
mncharity I note gimme5, given '3 || 4', doesn't seem to actually mention the op anywhere. 00:12
TimToady strange 00:14
TimToady I think I need to fix the cycles differently to avoid losing operator info like sym 00:45
decommuting &
mncharity ah, ok. 00:57
pugs_svn r22601 | putter++ | [elfish/STD_blue] Continuing to adapt IR constructors to gimme5. 01:24
ruoso hmm... s1p_array doesn't support push yet... 01:30
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:31
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?
ruoso mncharity, hi... the first page of the wiki explains it quite extensively 01:34
specially the ROADMAP and Changelog parts
mncharity thanks 01:35
ruoso mncharity, but there are some cool tests in the test/ directory
specially the .m0ld files
mncharity, one of my favorite tests is the test/35 01:36
mncharity looking... 01:37
ruoso that test demonstrates how SMOP implements lazy grep/map
mncharity :) 01:38
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.
ruoso well.. the dispatcher itself will be in m0ld probably...
unless pmurias manage to get mildew running more things quickly 01:40
which will then mean that we might have the sub dispatcher written in P6
mncharity, but the method dispatcher is already going to be written in P6 anyway
mncharity, it should be written in the src-s1p/P6Meta.pm class 01:41
which is the 'default' p6 HOW implementation
mncharity P6Meta interesting
ruoso and then there's src-s1p/Object.pm 01:42
our next major milestone is compiling both P6Meta and Object
which will mean that we've bootstrapped our type system
then it's just a matter of writing the built-in types in Perl 6 01:43
and the native types in the RI DSL
which is the final step before porting the actual compiler to smop
mncharity what are you parsing P6M and Obj with? 01:44
ruoso we aren't yet
we plan to parse it with STD
that's what mildew is about
actually, it should already be parseable by std... 01:45
hmm... it doesn't... it seems STD doesn't like pod yet 01:47
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.
ruoso mildew is turning STD parse tree (actually it's viv AST iirc) into m0ld 01:49
I'm not sure it's actually the same thing of STD_rgb
mncharity re it's viv, yes 01:50
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)
;)
mncharity STD _accepts_ Object.pm... ah, nm. :) there advantages to exploring two approaches to the same thing after all. 01:53
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:56
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
ruoso for some reason STD accepts 'my List of Method @foo;' but not 'my List of Attribute @foo;'
std: my List of Method @foo; 01:58
p6eval std 22602: OUTPUT[parsed␤]
ruoso std: my List of Attribute @foo;
p6eval std 22602: OUTPUT[parse failure␤]
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.
ruoso mncharity, well... the line of where it's really AST and where it's an OPTree 01:59
it's a very thin one
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
mncharity, and eventually porting the compiler itself to smop
TimToady, any expected reason for std accepting 'my List of Method @foo' and not 'my List of Attribute @foo' ? 02:01
ruoso mncharity, anyway... there's a very important task we didn't start yet... which is writing "method dispatch()" in P6Meta.pm 02:03
"method dispatch()" is the method that implements method dispatch
ruoso .oO( bootstrap is a curious thing, isn't it? )
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
re "bootstrap is a curious thing", ! :) !
yeah, despite all the crud cruft and slogging, I truly love it.
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...
ruoso hmmm... I have a reason to think that, I know I do... it's somewhere in my brain... 02:06
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.
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...
as long as it runs...
I think my concern is really about having the separation of compilation and runtime 02:09
but I'm too asleep to think...
later &
ruoso zZzZzZzZ
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.
g'night rouso 02:10
good night all &
partclCoke yawns 03:04
pugs_svn r22604 | lwall++ | [STD] revise cycle removal to preserve op fields other than PRE and POST 06:00
pmurias_ ruoso: actually it should be possible to use (a slightly modified) mildew IR to target other backends 07:05
pugs_svn r22605 | pmurias++ | [mildew] unfinished infix:<=> handling, t/pure_prototype.t showing how far are we from defining a method 07:11
pmurias_ ruoso: have you seen mildew --desugar? 07:12
mallory_ hi, agentzh 07:26
agentzh mallory_: hiya 07:29
mallory_ :D
agentzh just a bit surprised to see you here :P 07:30
mallory_ just walk 07:46
ruoso pmurias, Can't locate object method "term__S_386identifier" via package "STD" at ../../src/perl6/STD.pm line 1002. 09:42
pmurias, does that mean I'm missing compiling something?
ruoso_ if a multi can be used anywhere a sub can be used, that means it should implement postcircumfix:<( )> 11:49
but considering lexical variants
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
this might mean:
1) that it goes looking in the CALLER for other variants
2) that calling postcircumfix:<( )> directly on the object means looking for variants only in that multi object ignoring all the lexical variants 11:52
3) that multi is not really a Code, but just a container, and therefore, it doesn't implement postcircumfix:<( )> at all
I should say that I'm assuming the (multi)sub dispatch is something external to each sub.... 11:53
I just realized that Multi is not even a type... 12:05
hmmm...
ruoso_ bbiab & 12:09
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:25
ruoso_ later & 13:14
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.
rakudo_svn r31946 | pmichaud++ | [rakudo]: spectest-progress.csv update: 204 files, 4380 passing tests 14:03
rakudo_svn r31947 | pmichaud++ | [rakudo]: Don't use leading '::' for storing generic type lexicals. 14:03
r31947 | pmichaud++ | This gets us closer to supporting interpolated namespaces.
rakudo_svn r31948 | pmichaud++ | [rakudo]: Eliminate <generic_binder> and remove '::' as a <sigil>. 15:09
TimToady so should it be ceil or ceiling? or ⌈...⌉ :) 16:49
moritz_ the answer is usually "yes" ;) 16:51
TimToady pugs implements the first two o_O
[particle]2 ceiling, please 16:56
we don't say floo for floor
TimToady but we say abs for absolute and sin for sine 17:03
sin for sine is completely as(sin)ine 17:04
I can kinda understand abs for absolute though 17:05
moritz_ and 'sin' is what you always use in math anyway 17:05
TimToady but the fact is that mathematicians write "sin"
but not "ceil" 17:06
they use ⌈...⌉
'course we've made it impossible to use |$x| :)
moritz_ I did a quick search with google code search for \bceil\b and \bceiling\b 17:07
ceiling: 121k
TimToady well, given that it's ceil in C
moritz_ ceil: 256k 17:08
TimToady can you tell what languages use ceiling?
or is it all in comments? :)
moritz_ it seems most is user defined, or in weird programming langues that I don't recognize ;) 17:09
public class Ceiling extends NumericFunction {
TimToady heh
moritz_ that might be over-engineering - but of couse I don't know that 17:10
*course
TimToady well, I think huffman probably calls for ceiling 17:11
TimToady and looking at how it's used in t/, I'm sure of it 17:13
push @p, $x unless grep { $x % $_ == 0 }, 2..ceil sqrt $x;
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.
TimToady ceil sqrt sounds like some kind of sea creature
It's possible with ferocious backtracking
but we don't do ferocious backtracking
ruoso hmm... ok... 17:15
(we could always change '|' to something not used by math)
TimToady |$x + $y + $z|
moritz_ 2+|$x|+3 # a junction, or a sum? 17:15
TimToady could have a +|...| circumfix, I suppose
and a -|...| circumfix 17:16
moritz_ I don't think it's a very good idea
TimToady me too
[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 :)
ruoso heh
[particle] abs-minded professors?
TimToady cringes
ruoso pmurias, mildew still fail to parse test-mildew/pure_... 17:18
pmurias, it gives me another error... but it still fails...
TimToady it might be that capture interpolation is too short, huffmanwize
pmurias_ ruoso: maybe, i'm the one with the old copy, checking... 17:20
ruoso: did you rm -fr v6/mildew/lex/
ruoso pmurias, yes
ruoso pmurias_, kill your ghost, please ;) 17:20
pmurias_ the irssi is run on a machine i don't can't ssh to and i'll have access to in ~2weeks 17:21
ruoso pmurias_, you can always /msg NickServ ghost 17:22
pmurias_ hmm?
ruoso pmurias_, /msg NickServ ghost pmurias yourpasswd
[particle] that will remove pmurias, then you can /nick pmurias 17:23
and /msg nickserv identify pmurias password
ruoso [particle], hi... have you seen my comments on multi? 17:23
[particle] ruoso: not anything since last wednesday 17:24
ruoso irclog.perlgeek.de/perl6/2008-10-14#i_620509
lambdabot Title: IRC log for #perl6, 2008-10-14
ruoso I'd really appreciate some thoughts on that...
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.
ruoso pmurias, oh... ok...
[particle] ruoso: aren't all subs multis unless declared only?
pmurias [particle]: no 17:25
[particle] rereads the spec 17:26
ruoso [particle], but it doesn't change the problem 17:26
[particle], either way you have lexically-declared variants...
pugs_svn r22606 | lwall++ | [S29] settle on "ceiling" 17:27
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
ruoso pmurias, yes... I see that way too... but the problem is, what does $multi.postcircumfix:<( )> do?
pmurias ruoso: |$x| isn't particularly good syntax
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
ruoso pmurias, that would mean creating a clone for the multi at every new re-declaration 17:30
(sort of, but the consequence would be the same) 17:31
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...
I mean... 17:34
considering sub dispatch fallback to the package lookup
or even CANDO
pmurias does it?
ruoso yes... sub dispatch is 'no strict'
pmurias no
ruoso pugs: &Foo::bar := sub { 1 }; module Foo { sub baz { bar() } }; say Foo::baz(); 17:35
p6eval pugs: OUTPUT[1␤]
pmurias ruoso: S02:2824 17:37
ruoso pmurias, I'm not sure I see what you mean 17:38
[particle] tries to follow, but is on the phone... 17:39
ruoso pmurias, "The postdeclaration may be in any lexical or **package** scope"
pmurias they are checked at compile time 17:40
ruoso pugs: module Foo { sub baz { bar() } }; say Foo::baz(); INIT { &Foo::bar := sub { 1 } } 17:41
p6eval pugs: OUTPUT[1␤]
pmurias S02:2831
ruoso hmmm... ok... I think I see what you mean... 17:43
but...
does that mean that no new variants can be added in runtime to a pre-declared proto?
I would doubt that
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
ruoso if Foo::bar() is a multi, what happens if you &Foo::bar := somethingelse()? 17:45
does it add a variant? 17:46
or does it replace the entire multi with all variants by a new thing?
pmurias i think it replaces the entire multi 17:48
ruoso so it seems it needs to be late-dispatched anyway... 17:53
and the cloning doesn't seem to solve the problem 17:54
pmurias what's the problem btw ;) 17:55
ruoso the problem is: 1) Multi isa Code? 2) .() looks in the CALLER? 17:56
mncharity @tell pmurias re mildew as duplication (last night), I was wrong. eg, elf doesn' 18:02
lambdabot Consider it noted.
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.
pmurias mncharity: hi
mncharity t duplicate rakudo. focus on "usable and p6" vs "solid foundation". distinct impacts on language dev, different pragmatics.
hi pmurias. :)
ruoso pmurias, so you think .() on the multi object causes an invocation on the variants inside that multi object only? 18:04
pmurias yes
mncharity potential to share ideas, code, blur together. similarly, mildew compliments elf's currently narrow focus on getting to bootstrap.
pmurias ruoso: but i might not see the big picture
mncharity: mildew tries to express everything in terms of method call 18:05
* calls
mncharity witness yesterday's(?) kludgery to force temp() back to being a scope_declarator, because updating to current spec isn't critical path.
ruoso pmurias, in my head it's one of 1) traverse CALLER, 2) call only this variants or 3) doesn't implement .() at all
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.
so, I was wrong to characterize it as duplicated effort.
back later. err, or perhaps more likely tomorrow. cheers. 18:07
pmurias mncharity: could common lisp handle doing everything in an OO way?
mncharity really have to run. 18:07
pmurias ok
TimToady what do multis have to do with caller? 18:08
it's all lexical
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.
TimToady define Multi
mncharity cheers. &
ruoso TimToady, the stuff that holds the variants 18:09
where each variant is a code object
TimToady we can have &code objects that represent multiple candidates 18:10
ruoso yes... but it can't represent all the candidates
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
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?
moritz_ or maybe &code is really a junction of multis?
ruoso itself?
pmurias buying food& 18:13
ruoso moritz_, that's not the issue...
the issue is the fact that we have several "variant container"s
TimToady any &code represents one or more candidates
ruoso but the sub dispatch need to find all declarations of &code in the lexical scope 18:14
which mean several objects holding each one several variants
the question is what happen when you &code.() on one of those specific objects...
TimToady well, the compiler finds the lexical variants, not the dispatch
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?
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
ruoso right... so let's leave caching aside by now
TimToady it affects anything that can see it lexically, where global is "most lexical"
s/most/outermost/
pmurias TimToady: is there a way to prevent adding a new variant at runtime 18:18
?
TimToady don't let your candidate list generate from any namespaces that can be changed at run time
if you put a proto in your outermost lexical, it hides anything outside it 18:19
ruoso hmmm
moritz_ a proto in an *outer* scope hides something? 18:19
moritz_ finds that confusing 18:20
ruoso moritz_, hides the outer outer scope
pmurias TimToady: and eval("multi foo {...}")?
TimToady an "only" sub also hides anything outside of it
without a scope qualifier, it goes into your current package
which gets looked at somewhere just outside your outermost ordinary lexical scope, I thing 18:21
*think
ruoso TimToady, I'm assuming the dispatcher is the one that looks in the package 18:22
TimToady, but pmurias pointed that pugs is wrong about being 'no strict' on the sub names...
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
TimToady which axis is $foo on? 18:24
ruoso ordinary lexical scope, which ends in the prelude-lexical
TimToady which includes package
ruoso not really... 18:25
TimToady if your current package includes $foo, you see it 18:25
whether or not it was declared with "our"
ruoso because 'our $foo' creates a local bind to $package::foo
TimToady, which is the other way to declare $foo, besides 'our $foo'? 18:26
(and besides my $foo also, of course)
TimToady package variables don't need to be declared
$::foo = 42 is enough
ruoso but then you need to access them through the package, don't you?
and that's a different lookup
TimToady the current package is implicit 18:27
PerlJam wait a second ... you still get a warning with stricture, yes?
TimToady but yes, $foo as an rvlaue fails under strict
PerlJam ah. ok
ruoso so... {package Foo; $bar = 1} is valid... 18:28
PerlJam goes back to lurking
TimToady but if foo() doesn't call through the package, there's no way to override prelude at run time with a multi
since all lexical scopes freeze after compilation
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?
TimToady if prelude defines a proto multi, then you can't see any multi of that name in GLOBAL
under no strict it's valid 18:30
ruoso TimToady, right... so it falls back to package lookup under 'no strict' 18:30
TimToady but $::bar = 1 is probably better style in Perl 6
ruoso or "our $bar = 1' 18:31
which is probably even better
TimToady but that can have ramifications if there are other packages in scope
and those ramifications may be good or bad
so yes, "probably" :)
ruoso that's the part of "under no strict, it *falls back* to the package" 18:32
which means that it will only lookup in the package if no strict *and* if no lexical is found
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...
'no strict' will be handled later...
package Foo { proto foo; package Bar { my multi foo (Int $a) {1} } } 18:35
ruoso TimToady, the above example shows the issue I'm trying to address... 18:36
the lexical declaration 'my multi foo' needs to be stored somewhere different from the outer 'proto foo'
because it's lexical 18:37
unless I'm just crazy and that is simply not supporte
TimToady probably proto should be limited to lexical scope
ruoso TimToady, that meaning the above example is not valid? 18:38
TimToady well "proto foo;" by itself is illegal syntax 18:39
regardless of whether we decide to require "my"
and if you have "proto foo () {...}" then the multi would be an inconsistent signature 18:40
a bare "my proto foo {...}" would merely hide any outer foo without constraining the sig
ruoso confused... 18:44
package Foo { proto sub foo ($a) {...}; package Bar { my multi foo (Int $a) {...} } } 18:45
TimToady, the above example seems more on-the-point...
TimToady that looks fine in the sigs, since Int is more restrictive 18:47
ruoso right... but where is the inner variant stored?
TimToady but as I say, we might require "my" on the proto to prevent run-time mods
either that, or the compiler can't actually rely on a proto in a package to mean anything 18:48
so it might as well not be there
the main point of a proto is to tell the compiler what it can assume for optimization
ruoso right... let me try to be even more specific...
TimToady otherwise the name hiding can be done with an "only" sub
ruoso package Foo { my multi foo (Str $a) {...}; package Bar { my multi foo (Int $a) {...} } } 18:49
TimToady illegal
ruoso oh... right...
so there isn't lexically-scoped variants for a multi
TimToady oh, sorry 18:50
misread
that's fine
and yes, those would be considered both viable candidates
and they compete on equal terms 18:51
ruoso but on the outer scope, only the outer declaration is seen
TimToady true
ruoso rigth...
that means we have two different storage for the variants
TimToady yes, &foo means two different things
ruoso what does it mean in the inner scope? 18:52
TimToady it means both candidates are used if you call foo($x)
ruoso that's sub dispatch
TimToady multi dispatch is sub dispatch
ruoso yes yes...
but I mean...
foo(); and &foo.() would mean different things? 18:53
TimToady no
ruoso so postcircumfix:<( )> needs to look in the caller scope for the other available variants 18:54
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?
TimToady the reason we have "only" subs is so that at least some &foo can know they have only one candidate at compile time
&foo is inside neither multi 18:56
if you will, &foo is the only sub that delegates to all multis of the same name that are visible 18:57
and if there is only one candidate, it can be coelsced with the the only at compile time 18:58
s/one/one possible/
*coalesced
but &foo is the "short name" abstraction, basically, and it might or might not represent multiple actual Code objects 18:59
ruoso that way &foo.() on a multi is undetermined 19:00
?
TimToady or maybe &foo is the Code object, and there are multiple Sub objects. not picky about the names 19:01
undetermined?
TimToady &foo.() is the same as foo() 19:01
azawawi rakudo: say "ping"
p6eval rakudo 31953: OUTPUT[ping␤]
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
*used 19:03
ruoso right... but bare &foo ?
TimToady bare &foo represents all candidates of that short name (unless otherwise bound)
&foo := &bar.assuming(42) can put a different candidate list into &foo 19:04
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?
TimToady if the package names are visible 19:06
which depends on where the proto (if any) is declared
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...
TimToady which is why I put the package inside prelude
TimToady all Code objects respond to .(), but some of them must dispatch to a shorter list of candidates. 19:07
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...
TimToady yes, and it would be good to include the innermost candidate as well :) 19:09
ruoso :) heh
ok...
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 .()
ruoso TimToady, it actually overloading .() just fits 19:11
TimToady fine if it works
ruoso s/it//
and the invocation only see the innermost declaration
TimToady whenever I get confused about roles I take it as a sign that I should let the implementations fight it out 19:12
&foo is intended to be a simplifying abstraction, yes
it represents the current overloading
ruoso ohwkay
TimToady lexically current 19:13
where that might or might not extend out through a run-time modifiable package
ruoso so my plan is...
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
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
ruoso TimToady, which then mean adding more candidates to the same Multi object
TimToady yes 19:16
and all the &foo in that block refer to the same Multi
ruoso yes
an inner Multi holds a reference to the lexical scope in which it was declared, giving a path to access the outer Multi object
TimToady but also note that postdeclarations can come from outer scopes as well :)
ruoso TimToady, the key is keeping late-dispatch 19:17
and having cache as optimization
TimToady right
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
TimToady and run-time late if packages are involved
ruoso hmm...
actually...
not really
(not what you've said, but what I've said 19:19
TimToady biab &
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:20
anyway... I think everything is settled now.. 19:21
pugs_svn r22607 | particle++ | [t] add more 'is export()' trait tests 19:22
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:23
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?
ruoso yes... the output doesn't make much sense... 19:25
pmurias ruoso: --desugar prints out the IR before it is broken down into opcodes 19:31
pugs_svn r22609 | pmurias++ | [mildew] fixed my, --desugar uses mold {...} instead of {...} 19:33
pmichaud std: sub foo() is export(:DEFAULT :others) { ... } 19:34
p6eval std 22608: OUTPUT[parsed␤]
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:35
pugs_svn r22610 | pmurias++ | [mildew] infix:<=> with a method call on the left side 19:44
pmurias TimToady: STD parses anonymous methods incorrectly 19:47
pmichaud std: 3 + :a :b
p6eval std 22610: OUTPUT[parsed␤]
pugs_svn r22611 | moritz++ | [t/spec] clarified where.t a bit, as suggested by TimToady++ 19:55
r22612 | pmurias++ | [mildew] anonymous subroutines 19:56
azawawi how can i autoflush $*OUT for prints in p6? 19:58
moritz_ did you look in S16? (I have no clue) 19:59
azawawi i only found a quick reference on it in draft S28 20:00
pugs_svn r22613 | moritz++ | [t/spec] some unfudging for rakudo, [particle]++ 20:01
azawawi moritz_: 'print "your choice:"; my $foo = =$*IN' does not show anything until you press enter... 20:06
moritz_ azawawi: which implementation?
azawawi moritz: rakudo & pugs 20:07
moritz_: and =<> returns -1 on perl6 without waiting for input on rakudo 20:08
moritz_ azawawi: yes, it's known to be b0rked :(
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
testing
pugs_svn r22614 | lwall++ | [STD] EXPR quit reducing too soon on unaries 20:24
r22615 | moritz++ | [src/perl6/Makefile] don't rm -rf lex/ on every 'make'. 20:26
r22615 | moritz++ | Use /usr/local/bin/perl in Makefile, because that's what all the scripts use
r22615 | moritz++ | anyway.
spx2 :) 21:12
meppl good night 22:55

Powered by Cro and the Raku® Programming Language.

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

Thank you!