At 5:00 PM -0700 7/14/06, [EMAIL PROTECTED] wrote:
Author: larry
Date: Fri Jul 14 17:00:12 2006
New Revision: 10215


Differentiate === from eqv and clarify semantics.
Redefine cmp and add leg operator for old semantics.
Add ! metaoperator.
Fix random typos.

Larry, this new version looks great.

A few small omissions or clarifications though ...

+=item * Binary C<cmp> is no longer the comparison operator that
+forces stringification.  Use the C<leg> operator for the old Perl 5
+C<cmp> semantics.  The C<cmp> is just like the C<eqv> above except that
+instead of returning C<Bool::False> or C<Bool::True> values it always
+returns C<Order::Increase>, C<Order::Same>, or C<Order::Decrease>
+(which numerify to -1, 0, or +1).
+=item * the C<leg> operator (less than, equal, or greater) is defined
+in terms of C<cmp>, so C<$a leg $b> is now defined as C<~$a cmp ~$b>.
+The sort operator still defaults to C<cmp> rather than C<leg>.  The
+C<< <=> >> operator's semantics are unchanged except that it returns
+and Order value as described above.

1. I suggest for parity (vs leg as exists eq vs ==) and clarity that you explicitly state the <=> semantics like you did for leg, rather than just saying "it was unchanged". Eg, amend the last sentence there to say specifically that C<$a <=> $b> is now defined as C<+$a cmp +$b>, especially since you don't explicitly say this anywhere else in Synopsis 3.

+[Conjecture: we could probably do away with C<!~>, but probably not
+C<!=> or C<ne>.]

2. I support eliminating !~ in favor of just !~~.

Unlike != or 'ne', which are each part of a set of 6 operators that remained unchanged as a whole from Perl 5 (so backwards compatability could be useful), the binding/smartmatch operator set that !~ belongs to was greatly changed, so there is no benefit to keeping !~ just because that syntax was in Perl 5.

3. The "Precedence" table at the end of Synopsis 3 currently does not reflect your latest changes. Most importantly, it is missing 'eqv' and 'leg'.

Also importantly, it is missing the ?| operator and friends, which in my case leads to confusion as to whether it belongs with the tight-or set or the bitwise operator set.

Less importantly, I would consider the main versions of the negated eqality operators !==, !eq, !~~ to be more important than the alternate != or ne forms; as it is, that table already just lists the more canonical versions of things like the zip operator rather than both or the alternate versions.

4. I'm confused regarding the ?| operator, which is only mentioned in this paragraph near the top of Synopsis 3:

        =item * Bitwise operators get a data type prefix: C<+>, C<~>, or C<?>.
For example, C<|> becomes either C<+|> or C<~|> or C<?|>, depending on
whether the operands are to be treated as numbers, strings, or boolean
values.  Left shift C< << > becomes C< +< >, and correspondingly with
right shift. Unary C<~> becomes either C<+^> or C<~^> or C<?^>, since a
bitwise NOT is like an exclusive-or against solid ones.  Note that C<?^>
is functionally identical to C<!>.  C<?|> differs from C<||> in that
C<?|> always returns a standard boolean value (either 1 or 0), whereas
C<||> return the actual value of the first of its arguments that is

First of all, this paragraph seems to confuse in my mind as to whether or not ?| is a bitwise operator. On one hand, it says that it takes 2 boolean values as input and or's them. On the other hand, it says that it is just like ||, which takes any kind of values as input, but that the latter returns the first actual value of the first 2 arguments, while the former doesn't. The || comparison suggests that maybe ?| belongs with the tight-or operator set rather than bitwise. It might help if some of this was clarified. Part of the confusion though is that ?| isn't in the operator precedence table.

-- Darren Duncan

Reply via email to