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