On Thu, May 21, 2009 at 2:56 PM, Dan Bron <[email protected]> wrote: >> Which characters should be treated as letters? Which should be treated as >> digits? Which should be treated as tokens? Which should be treated as >> whitespace? How will this effect code written with this version of J when >> later versions of J become available? > > But it isn't as bad as all that. Unicode prescribes a lot of this, and > where it doesn't, or it conflicts with a J design goal, we can make our > own decisions.
For example, should we allow J to assign definitions to APL tokens (using =:)? If so, does what does this mean for APL's assignment arrow, and quad? If not, what kind of burden does this put on our J implementation team? > Perhaps we could take cues from other languages pursuing this path (UTF8 > identifiers; e.g. Perl6). Perl6 is, in essence, a language for writing parsers, and may never be completed. Do you really think this would be a good model for J? >> Right now ... the only universally viable subset of utf-8 is >> ascii. > > I agree patience is warranted. But if we were really eager to get Unicode > identifiers in the language soon, we could adopt some Punycode-like > translation layer. Where Unicode is viable, it would be presented. Where > it is not, Punycode(ish) would be. If you want to write something like this, I would be willing to give it a try. Thanks, -- Raul ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
