On Thu, Apr 14, 2005 at 11:08:21AM -0600, John Williams wrote:
: Good point.  Another one is: how does the meta_operator determine the
: "identity value" for user-defined operators?
: 
:     (1,2,3,4,5) >>my_infix_op<< (3,2,4)
: 
: Maybe we should say that the excess length is simply copied unchanged.
: But some might argue that not calling the op for each element would be
: cheating somehow.  That's not my position, but I cannot think how to
: refute it right now, if you want the side-effects.

One naive possibility is to supply one identity value per precedence level.
Then you could get 0 for addition and 1 for multiplication.  Doesn't
really work though, given there are so many different kinds of addition
and multiplication lumped together.  Arguably the identity value for %
is Inf.

Another approach to get the side effects would be to assume that
whatever "meta" code is actually calling the scalar operator is
smart enough to coerce ordinary undefs into "undef but identity"
or some such that each individual operator would know how to deal
with rather than generating an exception/undef.

: > What I ask myself is wether (1,2,3) »+ 1 should be a syntax error or just
: > a different form to express the :(List,Scalar:&) case. BTW, I know that
: > &infix_prefix_meta_operator:{'»'} isn't mentioned in A12.
: >
: > > I could be wrong, though; I can't find any support for it in the design 
docs.

We decided that binary ops should always just have »« on both sides,
since it's essentially just a single "dwim this" bit of information.

Basically, »« is just a flagrant value of "1".

: "Replicate dimensions" is specified in the first version of A3.
: 
: The length issue was resolved on the mailing lists.
: Could someone add the ruling to S3 to answer this FAQ?
: 
: I believe the fine points fall out like this:
: 
:    @a >>+<< 1    # replicate
:    @a >>+<< (1)  # replicate: (1) is still scalar
:    @a >>+<< [1]  # extend: [1] is an array (and will auto-deref)

Yes.  Parens in scalar context do not automagically produce a list.
Comma is another matter, so

   @a >>+<< (1,)

turns out to be the same as

   @a >>+<< [1]

since there is no scalar comma operator in Perl 6.

All that being said, it's almost certainly the case that (1) is
a mistake.  and should perhaps produce a warning: "Useless use of
parentheses" or some such.  Not that we frown on useless use of
parentheses in general, since they're often clarifying precedence.
But nobody should be confused about the precedence of a simple term.

Larry

Reply via email to