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!
In reply to Re^2: Contexts and Perl 6
by John M. Dlugosz
in thread Contexts and Perl 6
by John M. Dlugosz
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |