David Green david.green-at-telus.net |Perl 6| wrote:
On 2009-May-29, at 7:53 pm, Darren Duncan wrote:
Thirdly, there are I'm sure a number of other aliases that could be
added to other ops, such as ≤ and ≥ for <= and >=, and ≠ for one of
the inequality operators, although that last one would probably make
more sense if = was the equality test operator, so maybe best to
avoid ≠ then.
Probably. I would really like to see the "obvious" symbols defined,
though, for two reasons:
1) Being able to use real symbols (e.g. ≤ instead of crude ASCII
approximations) will make Perl code look ever so pretty and make all
the other kids envious. (Envy is, of course, one the great
programmers' virtues, the one that makes us steal all the best bits
from other languages!)
2) It will discourage people from abusing operators that already have
well-defined standard meanings. For example, if there is no ∑,
somebody might be tempted to use it for multiplication; or to use √
for checking something; or + for concatenating strings, etc.
I agree. The original non-ASCII characters, introduced 9 years ago, are
at least Latin-1. But in for a penny, in for a £, eh? The symbols ≤,
≥, and ≠ are u+2264, u+2265, and U+2260 respectively. That's pretty far
afield from Latin-1 or any national "code page" character sets.
They are part of the "Mathematical Operators" block at U+22xx. Checking
the fonts installed with Windows, coverage of that block is very
sparse. But, those three in particular, and a hand full of others, are
present in most fonts, including plain (not the Unicode) Arial, Courier
New, and Lucida Console. Even most of the ornamental fonts have those
three. One reason might be because ≥ and ≤ are in the DOS "OEM code
page" from ancient BIOS history.
Now the existing « » synonym of << >> is a "digraph" which I believe is
mapped at the parser level. Is that because the quoting needs to be
understood at a deeper level than just defining operators? I'm
wondering if there is any benefit or necessity of making <= and >=
"digraphs" for the single-char form, as opposed to just making the
operators synonyms. I guess the latter means that any overloading would
have to cover both explicitly to avoid confusing people.
Note that ≥ and ≤ are "bidi mirroring" characters in the Unicode
Properties. So if someone were crazy enough to use them as brackets,
then the digraph equivalent should work as well, right?
Anyway, I support the idea of making ≤, ≥, and ≠ the principle operators
and having <=, >=, and != as synonyms for them. But, the synonyming
would need to be automatic and complete, so that someone can overload
infix:<≤>, for example, and someone else using that module can write <=
and no worries. Although personally I think someone defining a new
class would just give it the Ordered role and supply the minimum two
methods for that, and then all the relational operators would just work.
I'd also like to point out that there are other variations, such as ≦
and ≶ so it is easy to get carried away. These others don't have the
widespread font support that the proposed 3 enjoy. We should leave all
the others for the math guys to use in specialized modules, and not be
in the core language.
I would also endorse using Π or π as synonyms for Pi or pi (or is it PI?).
The Latin-1 fractions ¼, ½, ¾ could be Rat constants, since I can't
imagine them being used for anything else. There is a full set of them
in the Number Forms block. But, those are not Letters. They have a
Unicode class of "Number, other".
I'm more interested in making sure that someone _can_ easily define ℝ as
a type name than in providing that by default.
