Juerd wrote:
> Ingo Blechschmidt skribis 2005-09-21 17:24 (+0200):
>>     multi prefix:<\> (Item $item) {...}
>>     multi prefix:<\> (@array)     {...}
>>     multi prefix:<\> (%hash)      {...}
> I keep forgetting. What's the rule for determining that the (Item
> $item) is used, rather than (@array), when one uses \$aref? It'd be
> bad if $aref dereferenced first :)

IIRC the rules aren't really there yet (but there're various proposals).
But, as you say, the rules will have to make sure that [EMAIL PROTECTED] calls 
&prefix:<\> with the signature of (@array).

> Is "Item" really a type?

I think so, see http://use.perl.org/~autrijus/journal/25337,
http://use.perl.org/~autrijus/journal/25365, and some
> Any is now really Any (includes Junction);
> the role hierarchy looks like this:
>          Any
>          /  \
>     Item    Junction

>>     # (The necessary magic needed for dealing with the proposed
>>     # [EMAIL PROTECTED], which would be equivalent to map { \$_ } @array,
>>     # is not included here.)
> Also, the magic for handling multiple arguments is missing.

This magic isn't needed, as there is no way to pass multiple arguments
to &prefix:<\> (except by explicitly calling &prefix:<\>, of course):

    \(1,2,3);           # is really
    \infix:<,>(1,2,3);  # thus &prefix:<\> gets a single array,
                        # not three arguments.

> What's the syntax for accepting a variable number of arguments, each
> of which can be anything, regardless of context? How do you find out
> what you got (array or scalar)?

I'm not 100% sure what you mean by "regardless of context" in this, err,
context, but I'll try anyway:

    # Naive approach (doesn't work)
    sub foo ([EMAIL PROTECTED]) {...}

    foo @array_containing_only_one_element;
    foo @array_containing_only_one_element[0];
    # XXX -- &foo can't tell the difference between these two
    # invocations.

    # Better approach
    multi bar (@array) {...}
    multi bar ([EMAIL PROTECTED]) {...}

    bar @array_containing_only_one_element;     # first variant called
    bar @array_containing_only_one_element[0];  # second variant called

    # But I don't think it's possible to make
    bar @foo, @baz;
    # cause @args to be bound to ([EMAIL PROTECTED], [EMAIL PROTECTED]), as 
slurpy parameters
    # automatically flatten @?ARGUMENTS (unspecced variable).
    # I started a thread about this a while ago, but can't find a link
    # to it...

> Does it even make sense to implement \ in Perl? Does it make sense to
> try and figure out a Perl signature for it?

It definitely makes sense to figure out an appropriate signature, as
a signature can help us to better understand what context \ supplies
to its parameters, how many arguments it accepts, etc.

It may or not may make sense to actually implement &prefix:<\> in Perl,
depending on the compiler, the backend, and the runtime.

>> Because the comma operator supplies list context, (@a, @b) flattens
>> @a and @b, so it's like @a.concat(@b).
> Ah, comma supplies list context regardless of the context the comma is
> in? Is this current, or part of your proposal? I thought comma would
> propagate context.

Well, (@a, @b) always evaluated to "@a.concat(@b)", so I guess the
comma operator supplies list context even in the current spec:

    my @c = (@a, @b);  # same as @c = @a.concat(@b)
    my $c = (@a, @b);  # flattens @a and @b as well (but, of course,
                       # $c contains a reference after the assignment.)

&infix:<,> definitely supplies list context in my proposal, as
&infix:<,> has a signature of ([EMAIL PROTECTED]), and slurpy parameters supply
list context. (See, figuring out &infix:<,>'s signature does make
sense :))

> This clarifies much. Thanks.



Reply via email to