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.
00:02 unobe_____ joined, Khisanth joined 00:23 Khisanth joined, Quellism joined 00:25 Limbic_Region left 00:41 mjk joined 00:44 macroron joined 00:47 imperator joined 01:16 lambdabot joined 01:24 mako132_ joined 01:31 pfenwick joined 01:42 particle_ joined 01:43 weinig_ joined 01:44 sri__ joined 01:48 b00t joined 01:50 unobe_____ joined, unobe_____ is now known as unobe 01:55 jserv-- joined 02:03 weinig_ is now known as weinig|sleep 02:19 unobe_____ joined 02:20 unobe_____ joined, unobe_____ is now known as unobe 02:30 SamB joined 02:44 FurnaceBoy is now known as MannishBoy 02:50 MannishBoy is now known as FurnaceBoy 02:56 Quellism joined 03:12 justatheory joined 03:34 nperez joined 04:01 Shabble joined 04:33 neoesque joined 04:50 FurnaceBoy_ joined 04:57 cmarcelo left 05:59 qu1j0t3 joined 06:21 pfenwick joined 06:55 iblechbot joined 06:58 Aankhen`` joined 07:10 mjk joined 08:12 Ymmv joined 08:20 marmic joined 08:22 lichtkind joined 08:33 elmex joined 08:37 lisppaste3 joined 08:55 Ymmv joined 08:56 penk joined 09:15 bjoern_h joined 09:18 buubot joined 09:55 andara joined 10:02 Ymmv joined 10:28 Ymmv joined 11:10 iblechbot joined 11:34 weinig|sleep is now known as weinig 11:38 chris2 joined 11:47 Limbic_Region joined 12:05 Khisanth joined 12:13 bjoern_ joined 12:16 cognominal joined 12:31 elmex joined 12:53 Ymmv joined 13:16 trym joined 13:17 justatheory joined 13:18 mako132_ joined 13:21 pfenwick left 13:44 FurnaceBoy joined 13:56 sahadev joined 13:57 Qiang joined, vel joined 14:07 ludan joined
ludan hi 14:08
lichtkind hello
PerlJam good $localtime 14:09
14:13 iblechbot joined 14:24 particle_ joined 14:51 DaGo joined 14:54 Hue-Bond joined 15:34 segv_ joined 15:45 kanru joined 16:11 sahadev left, sahadev joined 16:14 macroron joined 16:16 jsiracusa joined 16:19 marmic joined, neoesque joined 16:23 szbalint joined 16:24 andara left 16:34 nowhere_man joined 16:48 merlyn joined 16:49 beerboybeeerboy joined, leku joined, leku left 16:54 shachaf joined 17:16 Limbic_Region joined 17:34 lichtkind joined 18:03 FurnaceBoy is now known as FB|afk 18:20 putter joined
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
18:29 shachaf_ joined
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
18:38 weinig joined 18:39 shachaf__ joined
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
18:46 weinig is now known as weinig|away
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().
18:49 FB|afk is now known as FurnaceBoy
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
18:55 FurnaceBoy is now known as FB|afk
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. :)
19:05 Aankh|Clone joined
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
19:29 jserv-- joined, weinig|away is now known as weinig 19:40 penk left, vel joined 19:43 vel joined 19:45 vel joined 19:47 vel joined 19:50 larsen joined 19:59 sahadev joined, vel joined 20:01 vel joined 20:02 Khisanth joined 20:03 vel joined 20:06 _SamB_ joined 20:16 FurnaceBoy joined 20:26 FurnaceBoy joined 20:33 mako132_ joined 20:44 vel joined 20:49 putter joined
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
21:34 justatheory joined 21:53 fglock joined
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
22:05 Hue-Bond left 22:06 jsiracusa joined
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
22:36 trym joined 23:03 Ymmv joined 23:05 rashakil joined 23:39 ruoso joined 23:41 Quellism joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!