> Darren Duncan wrote:
> > For the record, my preference is to have the generics be the
> > shortest, [==,!==,<=>,<,>,<=,>=], and use [+,~] prefixes for Num or
> > Str casting versions. And lengthen the bit-shift operators to use
> > thin-tailed arrowheads as you suggested.
> I like this proposal for its orthogonality.
Bzzzt, wrong language!
But Perl isn't an orthogonal language, it's a "diagonal" language.
For what it's worth, I don't like the proposal because I was already
having trouble getting my head round the number of different operators
for asking "is this thing at least vaguely like this other thing".
Please can proposals for new operators (not just operators, for that
matter) be supported by examples along with the form:
Look at this awkward code (which could plausibly occur in the wild),
and look how less awkward the code is when rewritten using my proposed
> And it allows to introduce some more binary boolean functions:
Woo, _more_ binary boolean functions -- what a boon!
> ?< inhibition ?> reverse inhibition
> ?>= implication ?<= reverse implication (dual of the above)
> ?== equivalence (dual of xor)
> The low precedence versions might be spelled inh, rinh, imp and rimp.
> Hmm, and eqv ;)
Personally I choose to use a language such as Perl in preference to,
say, 6502 Assembly Language, to avoid operators being non-intuitive
sequences of three letters.
> BTW, could we define that the arithmetic shift ops do just that,
> whereas the string ones do logical shift? And in addition that for
> the bit inversion +^$a == -1 - $a holds? Note that -1 == +^0.
Does that assume a two's complement system? Is that a safe assumption
to make about everywhere Perl 6 will run? (Is it even a safe assumption
to make about Perl 5?)
> Note further that in infinite precision the arithmetic shift left
> maintains the sign ...
Do we expect Perl 6 to be running on infinite-precision systems?