Enabling the language to handle Unicode, and allowing the use of Unicode at the source code level, are two quite distinct decisions, each with their own sets of implications and caveats.
If some aspects of the language require the programmer to use Unicode symbols to use it, it has the potential to prevent those without Unicode enabled tools from using those features. This goes beyond the immediate problem of how to type the code in your favourite editor. How does grep (or cvs or PM's super search or ... ) handle Unicode?
There is also a pretty fundemental conflict with a world that still typically wants shared code to respect an 80 (or 72) character line width and eshews the use of the tab character for all the various reasons; and a world that allows or requires the use of Unicode for writing source code.
It seems to me that being the first language that allows, much less requires, Unicode symbols in source code is fraught with problems. Until the toolsets available to deal with source code catch up, it creates a big problem for the interchange and manipulation of that code.
Of course, the toolsets won't become available until there is a need for them!
Maybe fully Unicode enabled Perl6 and Parrot are just the things needed to allow the tools to be written, but does anyone foresee the existing tools being rewritten? Or the world at large adopting them if they were?
When IBM gave APL to the world, they also had the wherewithall/muscle to produce special keyboards (pic Look for the red symbols. It doesn't do justice to the real thing which were huge, heavy, and a dream to type on. The first time I saw one it reminded me of nothing more than the ZX-81 keyboard! :).
I don't think Perl6 could hope to do the same. Whilst emacs/vi configurations to enable unicode compositions can be made available, that still leaves a lot of tools with problems.
The UK "went metric" back in 1972 and yet road signs are still in miles, beer is sold in pints, land is measured in acres not hectares and even many of those things which must now be sold in metric units (for legal reasons. Traders have been prosecuted for selling bananas by the pound!), are still the old Imperial things measured in crudely rounded metric units. 2" x 1" timber is sold as 50mmx25mm. 1/2" plaster board is sold as 13mm.
As of 2000, the only non-metric units allowed were:
33 years on and we're still in the mix and match world of Imperial and metric units.
The current (latest, greatest) aim is to be fully metrified by 2009 (except for road signs!).
I think that Unicode is going to take a similar amount of time to become pervassive. Despite the speed, and it is ever increasing, with which things change in the world of IT and computers, human beings have an innate reluctance to change. I think that it will take at least one "working generation" (say 35 or so years) for the greater majority of those in the industry at the levels of influence needed to impose such changes, to arrive at a concensus that Unicode is both desirable and necessary.
Personally, I wish it were otherwise. I do however see considerable problems with using Unicode. Whether the difficulty of typing it; the problems in trying to convey Unicode symbols verbally; comparing Unicode symbols and their ascii-ized, n-graph equivalents; displaying them; printing them; interchanging code containing them.
I guess the question comes down to whether Perl6 can stand the additional levels of 'reluctance to adopt' that these problems will create, on top of those already murmuring in the background?
In reply to Re: Perl 6 and Unicode Operators
by BrowserUk
in thread Perl 6 and Unicode Operators
by mugwumpjism
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |
