Re: sharp ß and ss in Ada keywords like AC CESS

[Georg Bauhaus <rm-host.bauhaus@maps.arcor.de>]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote:

>> "acceβ" will be an error, because it mixes two "alphabets",
>> Latin and Greek.
> 
> ß has nothing to do with Greek alphabet, it is a ligature promoted to a
> separate character. 

"acceβ" has a Greek BETA, and the compiler would have noticed.

>> The compiler will detected the syntax error.
> That was not my question. It was what to do with this:
OK, different question.

>    type Acceß_Type is access Integer;
>    type Access_Type is access String;

I'd prefer them to be the same in this particular 
case, since the Swiss model (which is without ß)
is working.

> Do these identifiers conflict?
> 
>    I : Integer; -- Latin I
>    І : Integer; -- Ukrainian I

Different alphabets, different identifiers. Obfuscation is
the work of the programmer. A requirement to use only 
one "alphabet" for an identifier is a countermeasure.
It is easy to write very confusing Ada in ASCII, too.

> Is ö Latin? Are k, u, w Latin? BTW, Latin script was all upper case.

Yes, they are to be classified as Latin, because
programmers are used to it, and the relevant standards
apply, too.  W is double-v or double-u if you insist that
history should play a part, etc. but this only complicates
the matter for programming, without need, IMHO.
.

>> - Cyrillic characters
> 
> "Cyrillic characters" is a wild mixture of various characters and
> ligatures of (like German ß) from different national Cyrillic alphabets,
> with borrowing from Greek, Latin and later inventions. There is no reason
> to treat combinations of those as something cohesive.

I think it is reasonable to define useful, simple sets of the
characters that people will consider related: It is easier to
write a text message in Danish on a dated phone if this
phone has French keys rather than Ukrainian keys. 
French is better in this case because ø might not be
on the keyboard, but most other characters are. Whether
Danish or French, the Inclusive Latin Alphabet lets me
write in either language. The inclusive Cyrillic Alphabet will
let others do the same. That is, write using sets of characters
that people will consider related, in this practical sense,
when using Slavic languages.

The real trouble is with geeky identifiers that,
for reasons of being cool, must allow the mixing of
alphabets, because employing transcription, transliteration,
or translation is about as cool as not writing
geeky identifiers at all...

>> But this should be fairly easy
>> to implement,
> 
> It is not about implementation, it is about understanding the rules without
> looking into the categorization tables.

If a word looks like a mix of Cyrillic characters,
then, to a compiler, it is Cyrillic. A programmer
seeing Cyrillic characters will, on average, be
right in assuming that he is seeing some
identifier written in some Slavic language.
No more, no less. If the rule says that only
one alphabet is permitted per simple name,
it reduces complexity for the reader of Slavic
language.

> 
> BTW, why "ΔT" should be illegal?

Yes, illegal if the alphabet rules apply. The solution
is just like in real life: 
When it is an operator, really, make it one.
When it is some prefixed hint, other conventions
have worked well, even in textbooks
When "delta-t" is the name of something in the
problem domain, chances are one can
find a specific name that is better than "delta-t".