Hi,
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
the
&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
http://svn.openfoundry.org/pugs/examples/:
> 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.
:)
--Ingo
