On 11/10/05, Austin Hastings <[EMAIL PROTECTED]> wrote: > Luke's Tuple proposal, aka Luke's Grand Unified Object Model, is way not > what we need for this. As far as I can see, LGUOM is an expression of > "Haskell envy" of brobdingnagian proportion.
The reason I refrained from linking to theory.pod was that I didn't want people getting distracted by a document that's 90% irrelevant to what we're discussing here. That other 10%, though, is Tuples--and they're exactly what's needed for representing an argument-'list' in its entirety. That is, after all, a large part of what they were designed for. > A rule that says "splatting > a list coerces all pairs into named args" works just fine. The > corresponding rule, "accessing the parameters to your sub as a list (not > using *%args) coerces all named args to pairs". Presto! Reversible, etc. 1) What happens if that list is lazy? You'd have to force the entire thing, just to check if there were any pairs hiding in it. What if it's an infinite list? What if you can't know whether it's infinite or not? 2) What if the list contains pairs, but you want to pass them as positionals? What if it might contain pairs, but you're not sure? What if you introduce a new named parameter (or change a parameter name), and what you thought was a positional pair now becomes a named arg? Your suggestion would involve re-introducing some of the 'magic' that real experience suggests we should be trying desperately to get away from. And look, if you really wanted to, you could define your own splat-style operator that works exactly as you describe. But I don't think it should be the default. > An alternative might be PHP-style arrays. But nobody wants that. The key difference is that while a PHP-style array can't decide whether it's an array or a hash, a Tuple *knows* that it has to be both (and more), in order to accurately represent the full power of Perl 6's argument system. (Also, Tuples might end up being immutable, but don't quote me on that.) > Tuple construction conflicts with a lot of things. Given the amount of > new (to me, anyways) syntax proposed in the rest of the document, I'm > surprised that LQe didn't unify lists and tuples (or push list > construction elsewhere). He very nearly does, actually (albeit with a handwave). But Tuple syntax (and the rest of theory.pod) is largely irrelevant here. (I personally think Ingo's `Tuple.new` might be sufficient.) Stuart
