>> Unicode has a *lot* of potential operators. > > Are all these for use in the core language though?
Not yet...but give us time! >;-)
> I was thinking about defining short names for the core stuff, and people > can use the thirty letter names for more complicated things.
Yes. But doesn't that amount to my HTML-entities-plus-Unicode-names suggestion?
> A good solution would be to support the Unicode names and codepoints, > and allow people to define their own entities with friendly names.
I fear that might not be a good solution.
I think it's terribly important that Perl 6 have standard -- and preferred -- ways of expressing standard things. That's why it has a standard switch statement, and a standard class declaration syntax, and a standard grammar specification mechanism, etc. etc.
We eventually realized that having 26 ways to structure a switch statement didn't actually help, and I fear that having 26 ways to write »+« won't be beneficial either. I suspect that having four ways (Unicode glyph, HTML entity, Unicode hex value, and Unicode name) of representing the common symbols and three ways (Unicode gylph, Unicode hex value, Unicode name) for everything else will be enough.
And, in any case, I'm sure if there's actually a demand for it, it won't be long before some keen individual produces an Entitiy::Rename module. ;-)
> I have a dim memory of last time I was forced to deal with anything that > was ASCII only, but to be perfectly honest in the case you cite here I'd > be happier with a hex editor than with those terribly long names :)
Acknowledged. But those terribly long names are also terribly descriptive, and I suspect there are others besides myself who would prefer cope with the terrible length of those terribly descriptive names rather than have to remember what the short but cryptic E<x224C> operator looks like.
Damian
