Front page | perl.perl6.language |
Postings from July 2006
Re: [svn:perl6-synopsis] r10215 - doc/trunk/design/syn
Thread Previous
|
Thread Next
From:
Darren Duncan
Date:
July 14, 2006 21:49
Subject:
Re: [svn:perl6-synopsis] r10215 - doc/trunk/design/syn
Message ID:
p06230900c0de179e845f@[192.168.1.101]
At 5:00 PM -0700 7/14/06, larry@cvs.develooper.com wrote:
>Author: larry
>Date: Fri Jul 14 17:00:12 2006
>New Revision: 10215
>
>Modified:
> doc/trunk/design/syn/S03.pod
>
>Log:
>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
true.
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
Thread Previous
|
Thread Next