Re: RFC 110 (v3) counting matches

Tom Christiansen wrote:
> 
> >And hashes are assembled just like lists anyways:
> 
> >   %hash = list get_key_vals;
> >   %hash = (key, val, key2, val2);  # same thing
> 
> Eh?  List context is conferred by the % on the LHS.  You need
> no redundant listification redundancy there.

I was trying to show that "hash" isn't a needed keyword, NOT that "list"
is needed here.

> Now, you *can* force list context, but I (and Larry, one of whose
> text I just quoted) don't see it as common, so it's not worth the
> word.  But it's not impossible, either, as you can use either the
> construct @{ [ ... ] } if you're in a string and trying to interpolate
> some function call, or simply through ()=... otherwise.

I know. But I've always thought this it too obscure. You only need one
trigonometric function, you know - everything else can be derived from
manipulation of sine. But we support 6. Why? To make things easy things
easier.

If you do need to force list context - and all of the example so far
have demonstrated you do from time to time - then *sometimes* "list"
makes more sense, just like *sometimes* "scalar" makes more sense:

    foo(list bar());         # easy
    foo( () = bar() );       # not as easy

    foo(bar());              # easy
    foo(scalar bar());       # not as easy

    my($arg1) = func;        # easy
    my $arg1 = list func;    # not as easy

    my $num = @a;            # easy
    my($num) = scalar @a;    # not as easy

The only thing you seem to be arguing against is clarity. I don't see
any disruption in the language here, or any reason "list" is less useful
than "scalar".

> Education is a wonderful thing.

I certainly hope this wasn't directed towards me.

-Nate