Ingo Blechschmidt wrote:
>Juerd wrote:
>
>
>>Ingo Blechschmidt skribis 2005-10-10 20:08 (+0200):
>>
>>
>>>Named arguments can -- under the proposal -- only ever exist in
>>>calls.
>>>
>>>
>>Which leaves us with no basic datastructure that can hold both
>>positional and named arguments. This is a problem because in a call,
>>they can be combined.
>>
>>
>
>Very true. This is why we need Luke's Tuple proposal [1].
>
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. 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.
An alternative might be PHP-style arrays. But nobody wants that.
>Basically:
>
> my $tuple = (a => 1, (b => 2)):{ ...block... }; # $tuple.isa(Tuple)
> # Tuples are ordinary objects -- they can be stored
> # in scalars, arrays, etc.
>
> # But splatting tuples unfolds their magic:
> foo(*$tuple); # same as
> foo(a => 1, (b => 2)):{ ...block...};
> # named arg "a", positional pair (b => 2),
> # adverbial block { ...block... }
>
> # (Yep, under the current proposal, tuple construction conflicts
> # with list/array construction. FWIW, I'd be fine with
> # using Tuple.new(...) as the tuple constructor.)
>
>
>--Ingo
>
>[1] http://svn.openfoundry.org/pugs/docs/notes/theory.pod
>
>
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).
=Austin
