pugs.blogs.com | pugscode.org | pugs.kwiki.org | paste: sial.org/pbot/perl6 | <stevan> Moose... it's the new Camel ":P | .pmc == PPI source filters!
Set by Alias_ on 16 March 2006.
ludan hi 14:08
lichtkind hello
PerlJam good $localtime 14:09
putter I'm probably being prematurely puzzled by this, but... 18:20
f(g()) where sub f(\$a){ rand > 0.5 ?? j.call($a) !! k.call($a) } and sub j($x){}; sub k(*@y){} 18:22
is g called in a scalar or list context? if it could be either, then its execution is lazily deferred until you know?? 18:25
PerlJam looks like scalar context to me.
putter "Any remaining variadic arguments at the end of the argument list are bound to the slurpy array (*@data above) and are evaluated in list context. " S06/List parameters 18:27
so k(g()) would do g in list context, no?
PerlJam yes. 18:28
putter ah, "Individual parameters may confer a scalar or list context on their corresponding arguments, but unlike in Perl 5, this is decided lazily at parameter binding time." S03/Parameters and arguments 18:30
It just hadn't occurred to me that with Captures, parameter binding time might be quite so late. 18:31
PerlJam: was that "yes", "yes, k(g()) would be listy, but f(g()) would still be scalary", or "yes, it could be either"? 18:35
PerlJam putter: the former (AFAIK. but I'm no expert)
er, I guess "the middle one" :) 18:36
putter ah. hmm. lol
putter if it isnt lazy, then delegatation has issues; if it is, p6 is a lazy functional langauge. which could be neat, but I wonder if it was intended. by repeatedly doing captures, the thread might execute an arbitrary number of subs before g actually gets called. 18:42
TimToady g() is not lazy.
putter :)
TimToady the delayed binding of context really only applies to things that are already objects 18:43
there's something in there about the context of a function being assumed to be list context if unknown.
but what a function returns is a Capture object, and that's what gets lazily contextualized. 18:44
putter ah, so capture param => unknown => list context for g
err, rephrasing, 18:45
PerlJam TimToady: Where did perl5's OO model come from exactly? 18:46
Limbic_Region just worked around an extremely bizarre p5 tie bug
TimToady bits of it came from Python, bits of it just from considering how to minimally hook up to C++ via XS. 18:47
Limbic_Region FETCH only gets called once
PerlJam TimToady: thanks, that jibes with what I thought (mostly :-)
putter f, because of it's capture param, creates a situation of unknown context for its arguments, and g(), being a function call in unknown context, defaults to list context. yes? 18:48
TimToady if g() calls want(), it will be told it's in list context.
putter waits for the other shoe... 18:49
TimToady but the return in g() is just a function that hands its Capture back
which gets installed into the Capture list of f()
so the binding of f() decides whether to flatten the return value of g().
putter ponders 18:50
TimToady too...
It's not quite what you want for MMD...
unless you count the type of the Capture as the "of" type of g(). 18:51
or peek inside it.
(to get the actual run-time type of the result) 18:52
I suppose MMD will ask g()'s return value for its scalar value in any event, which if g() returns a list, might just say "I'm still a Capture, if you want a scalar." 18:53
But if it just returns a scalar, that's what you get without the Capture wrapper. 18:54
(just thinking out loud here...)
Or maybe the listy version just turns into a List object.
(of course, you can always flatten earlier with [,]) 18:55
TimToady but you want to return a Capture so that you can say @a := g() 18:56
or $b := g()
The whole point of a Capture is that it hasn't decided what its context is yet.
Is this making any more sense now? 18:57
PerlJam Will want() return a junction in the presence of multi-methods? 18:58
TimToady I don't think so. I'm not terribly fond of want() any more. 18:59
I think declaring the return type is much more useful.
PerlJam Are you unfond of want enough that it will be extirpated? 19:00
TimToady No, but I'm not interested in slowing anything else down in order to support it.
PerlJam Seems like it's still useful but occasionally is allowed to return an "I don't know" ansswer
TimToady In which case the best response is often to return a proxy object that lazily produces the desired value once the context *is* known. 19:01
there could be some syntactic relief for that so we don't always have to close over all the closures that might be returned if we know the context earlier. 19:03
Or maybe some kind of tiebreaking MMD based on context.
where the default method just closes a call back to the MMD dispatcher for later lazily. 19:04
PerlJam Seems like it would be easy for the programmer to write some circular logic where one sub's context is dependant upon another's and vice versa (though I guess that's easy to detect too)
TimToady (or however you say that in English...) 19:05
I think ignorance and apathy are a good default. :)
TimToady "I don't know and I don't care" works pretty well for questions of context. 19:06
I think returning Captures but resolving them lazily for MMD is probably a reasonable approach. 19:08
wolverian "You'll have to tie me down and beat me with a hammer before I tell you!"
TimToady they can be resolved more eagerly for single predeclared subs, or for multis that have a proto. 19:09
(in which case g() even knows its context from want(), probably) 19:10
PerlJam TimToady: well, it sounds good from where I'm sitting (in as much as I can't really think of anything that would fatally wound the idea) 19:13
putter my take-away line is something like, lhs's establish context, so Closures, arg#!@!, Captures, being a generalized rhs, will sometimes have their arguments evaluated with unknown context, so the context defaults are used. 19:14
TimToady Basically, as with all the rest of Perl 6, we're just ignoring the fact that it's impossible and doing it anyway. :)
PerlJam putter: I would say that "as long as you don't force evaluation in a particular context, you don't know what the context is and often don't need to know (yet)" :) 19:15
putter: for your "sometimes" case 19:16
TimToady yes, it's okay for Capture context to call functions eagerly, as long as the eventual objects migrate through unmolested somehow.
Most "real" objects (arrays and hashes and scalars) don't care until binding time what there context is. 19:17
*they're
*their
take your pick :(
putter I'm still a bit fuzzy, but all set for now. Thanks. :) lol 19:18
TimToady Oh, don't bring sets into it. :P
putter :)
PerlJam putter: you're only fuzzy when I'm not wearing my contacts.
particle_ makes sure he's in #perl6 and not #pun6 19:19
PerlJam putter: or you've somehow gotten fur stuck to yourself, but I don't even want to know what happened there!
TimToady (speaking of contacts...)
well, I've gotta run off to a lunch.
munch & 19:20
putter bye. thanks again. 19:21
PerlJam fuzzy wuzzy was a putter, fuzzy wuzzy liked to mutter, fuzzy wuzzy had trouble rhyming at this point ;-)
putter Extreme Programming, 2007 - "Since if it's not coded, it doesn't exist, it eventually proved possible for coders to maintain a code-all-implementation-paths superposition. This had the now familiar side effect of making them appear fuzzy." 19:26
cheers & 19:27
putter hmm. upside, pugs now builds fine. 20:50
downside, uncommenting the Test config.yml line, make clean, make, results in a pugs which seems _slower_ than before. For both -e 'say 3;' and -e 'use Test;'. Just an off-the-cuff observation. I haven't looked at it real hard. 20:57
But 'use Test' is ~6 cpu sec vs ~9 cpu sec. So not a subtle difference. 20:58
puzzled & 20:59
theorbtwo asdfasdfsdfasdf 21:20
buu Fascinating. 21:24
fglock is :ratchet passed as a parameter to subrules? specifically to <ws>, which would not backtrack inside a 'rule' but would backtrack inside a 'regex' 21:55
TimToady no, every regex keeps its own idea of ratcheting. if the <ws> backtracks it does so as a whole, unless the definition of <ws> includes its own backtracking. 21:58
I think the standard <ws> probably doesn't backtrack internally.
fglock TimToady: does :perl5 rules called from plain 'regex' backtrack from them? (this is a bit difficult to implement, if we use different engines) 22:01
regex any :p5 {.*} regex xx {x<any>x$} - does matching "xxx" work? 22:04
TimToady fglock: it would be nice if that could work. that probably means the implementation of :P5 really wants to just translate the regex to P6 form and use the same engine, rather than trying to use an engine that can't take continuations. 22:17
Alternately, it could just refuse to work if called in a context that requires backtracking into a subrule. That approach might be okay for a bootstrap. 22:19
That might also be the best we can do when calling into a subrule defined by a different language. 22:21
(unless we can get at the original text and emulate in P6)
The other alternative in such a case is to provide our continuation to the subrule to be called recursively, assuming the other engine has the capability of calling back to us somehow. 22:23
(That's basically how the P5 engine works with respect to itself--it recurses deeper to test the following pattern, even if that following pattern is "shallower" in some sense.) 22:25

Powered by Cro and the Raku® Programming Language.

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

Thank you!