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.

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?

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

Your suggestion would involve re-introducing some of the 'magic' that
real experience suggests we should be trying desperately to get away

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.)


Reply via email to