At 10:30 PM -0800 11/11/06, Jonathan Lang wrote:
Note that this is two competing suggestions: one where '==' means
'generic equivalence', '+==' means 'numeric equivalence', and '*=='
means 'string equivalence'; and another where '*==' means 'generic
equivalence', '==' means 'numeric equivalence', and 'eq' means 'string
equivalence' (with '<', '>', etc. following suit). The goal of the
second proposal is to leave existing operator names unchangåed, while
the goal of the first proposal is to provide a consistent and
intuitive naming convention.
<snip>
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.
If this practice is followed, then we get these benefits:
1. Better self-documenting of code.
2. Better visual consistency of comparison operators - easier to learn.
3. Fewer base operators and/or fewer alternate shorthands - simplicity.
4. Eliminate the alphabet soup and related ugliness.
5. Better huffman coding because most people will
want to sort their values by their native types;
people normally want to sort Str as Str and Num
as Num, and plain == etc will do that. I don't
see any use of weak types as reducing the
benefits either.
6. In my mind, bit shifting is a less commonly
coded activity, so making those ops a bit longer
shouldn't hurt anything.
-- Darren Duncan
