in reply to Re: Contexts and Perl 6
in thread Contexts and Perl 6

I see your point: MMD, moreso than ordinary virtual function dispatching, requires information flow outward, like we're used to in most other languages. That contradicts the idea of strong typing flowing inward.

So if we do away with want, we just have the odd built-in parts left. The parser behaves differently in scalar or list context, like with Perl 5. No real need for others. Can we do away with it totally, leaving only a faint shadow of the concept as the way the non-context-free grammar works?

I'm thinking, but haven't quite crystallized on it, that given an Array object, putting it in item context just returns the same object. But the situation is not the same! Or, did the surrounding code already decide what it's going to do with it (e.g. STORE it in an item container) before calling the Item coercion? I like that better, because objects don't behave differently based on "context".

I do like the idea of a function being able to short-circuit its logic if it knows its being called a certain way. But I realized that this is just a poor-man's way to overload on return type.

Thinking about its intended use, and modeling it as overloading, I'd say the selection would be ranked based on the way information is distilled from the main type. By default, native type > Positional > Numeric > Integral > Bool. If done as overloadings, then the function could declare the rankings relative to the others. If done using wanted, want would return a junction and the code could decide which was more important. Basically just order the when clauses in the desired order, and it won't care that the given is a junction.

Other languages don't have a mechanism to make that efficient. But a Functional language or other pure design approach would have these very things: only one function to return the list, and the caller decides cardinality from that. You have functions for lists, and you don't need to "cross" all the list-related operations with all operations that return lists!

Replies are listed 'Best First'.
Re^3: Contexts and Perl 6
by TimToady (Parson) on May 19, 2009 at 16:07 UTC
    The parser behaves differently in scalar or list context, like with Perl 5.
    Actually, no, unlike Perl 5 the Perl 6 parser has no clue about scalar vs list context, which is completely driven by run-time binding so that context can be lazy. The only place the parser appears to pay attention to this is in choosing how to parse assignment based on the form of the left side, but this is merely the application of a precedence limiter to the right side so that the operator precedence parser knows whether to stop at the next comma or not. The only semantic distinction that heavily influences parsing is whether a name is predeclared as a type or named value (in which case the parser will not look for function arguments), but this also is not related to run-time context.
[reply]
      Very interesting, thanks.

      I see in the Synopses where context behavior is being replaced by typed objects; e.g. "undef in scalar context or () in list context" replaced by "Nil".

      So, is there anything left of the concept of context flowing inward in the manner of a contextual variable?

      —John

[reply]
        The basic problem is one of time travel. Context variables work because you set them up before you ever call the function, because statement boundaries provide a sequence point. 
        my $FD is context = open($file);
later(1,2,3,sooner());

        [download]
        So both sooner and later see the value of $*FD in the dynamic context. However, the type context of sooner is not known when it is called, because it it provided by the binding in the later call. (MMD only makes this worse, not just because you have multiple possible type contexts, but because the use of the actual return type for MMD introduces a chicken and egg problem.)

        It would be possible to define a form of laziness that would at least let sooner() see the possibilities, and perhaps even negotiate a unification between the two lists of possibilities (the return possibilities and the binding possibilities). One could imagine that the want function actually takes a continuation, and returns that to be bound lazily, and then continues executing once it knows how it will be bound. That could work directly for dispatch to an "only" version of later (assuming you don't depend on side effects in sooner happening before the call to later). For multiple dispatch we would presumably have to return (along with the continuation) some kind of list of possible return types for MMD to work with, or perhaps just the most general type, if we decide all coercion is to be managed by MMD rather than by want. Or we could take the approach you suggested and do the unification in sooner's switch statement, but then the call to sooner would be driven by the dispatcher, not by the actual binding.

        But this is all conjectural, since at least for 6.0.0 we're aiming to create something implementable on platforms that have difficulty with time travel. There's nothing in the current design that exactly requires continuation support; even resumable exceptions are designed to work on systems without first class support for continuations (that is, we don't unwind the stack till after exception handlers are run, so resuming from an exception is just a return). Lazy lists can be emulated with closures and iterators.

        So for now, we put our thumb on the scales in favor of multiple dispatch using a set of already-computed values of known type, and leave the door open for time travel in the future. We don't exactly know how to install a time-travel booth, but we're saving a spot for someone clever from the future to come back and install one for us, sooner or later. :-)

[reply]
[d/l]
[select]

In Section Meditations