Robin Berjon wrote: > I wasn't proposing to come up with short names for all the Unicode > repertoire, just for the characters that are used as operators :) That > shouldn't be too long, should it?
I'm not so sure about that. I can already see those mathematician/physicists
gazing hungrily at the following blocks:
Superscripts and Subscripts (41 codepoints) Mathematical Operators (256 codepoints) Miscellaneous Math Symbols-A (27 codepoints) Miscellaneous Math Symbols-B (128 codepoints) Supplemental Math Operators (256 codepoints)
Unicode has a *lot* of potential operators.
Are all these for use in the core language though? I was thinking about defining short names for the core stuff, and people can use the thirty letter names for more complicated things. I guess they could also use E<xNNNN>, no? A codepoint may be better than the unreadably long name.
A good solution would be to support the Unicode names and codepoints, and allow people to define their own entities with friendly names. That, plus predefined short names for core language ops.
> I have nothing against using the Unicode names for other entities for > instance in POD. The reason I have some reserve on using those for > entitised operators is that E<LEFT LOOKING TRIPLE WIGGLY LONG WUNDERBAR > RIGHTWARDS, COMBINING> isn't very readable. Or rather, it's readable > like a totally different plot with its own well-carved out characters, > intrigues, and subplots in the middle of a book.
Yes, but when you download the Debug::Heisenberg module, surely it will be better to be able to view:
my sub infix:? {...}
$eigensanction = $state ? $event;
at least as:
my sub infix:E<LEFT LOOKING TRIPLE WIGGLY LONG WUNDERBAR RIGHTWARDS, COMBINING> {...}
$eigensanction =
$state E<LEFT LOOKING TRIPLE WIGGLY LONG WUNDERBAR RIGHTWARDS, COMBINING> $event;
if that's all your ancient ASCII device is capable of?
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 :)
-- Robin Berjon
