Re: Unicode in C--: a proposal

> The C-- specification asks for suggestions for what to do about Unicode.
> Here's my proposal.

I'm currently in the middle of adding unicode support to a commercial
product, which includes a programming language.  My experience so far
suggests that:
- Unicode is a big can of worms,
- The Unicode standard is more complicated than you think,
  even if you have spent some time reading the documents at unicode.org.
- Don't assume that other authors who have added unicode support to
  their programming languages know what they are doing--some of the
  designs out there seem pretty broken.

The best way to approach this issue for C-- is to have a clear idea
of what specific problems that C-- users are having in the field,
then design solutions for those problems, after taking the time to
obtain a clear understanding of the pitfalls of Unicode.

> Non-ASCII characters
> are treated by C-- as syntactically equivalent to the ASCII letters,
> and so may appear freely in names.

This means that non-ascii control characters, non-ascii white space,
and even non-ascii newline characters are treated as letters, and
can appear in identifiers.  Not a good idea.

It would be better to follow the guidelines in the Unicode standard
for the syntax of identifiers in programming languages, than to do this.

Why bother expanding the set of characters legal in a C-- identifier
at all?  What problem does this solve?

Since C-- is a compiler back-end, I assume that the set of
characters legal in an identifier is determined by the need to be
compatible with existing object file formats, linkers, and external
libraries that a C-- program might need to link to.

So, if there are platforms on which a C-- program cannot link
to certain functions in certain libraries because the definition
of a C-- identifier is not expansive enough, then that would be
a good reason to change the definition of a C-- identifier.

Doug Moen.