Re: Ada generics

[Georg Bauhaus <bauhaus@arcor.de>]

On Thu, 2006-12-28 at 11:59 +0100, Dmitry A. Kazakov wrote:

> > so it cannot ignore
> > Unicode issues if it wishes to allow Unicode characters in identifiers.
> 
> Which is a BAD idea, IMO.
> 
> We cannot know anything about properties of letters in Klingon. As a
> practical example consider Russian where e can be used (and is) in place of
> ё see (http://en.wikipedia.org/wiki/%D0%81), but not reverse. Or, maybe we
> should make Ada compilers capable to detect program written by Germans to
> consider ü and ue same?

Yes, writing source code is a question of being practical, which is
probably not easily formalized... An international character set
for portable programs seems to leave only some choices open when
they should be practical, does it not?
Naturally, mathematical fancies like being complete,
free of contradictions, etc. are out of the question when it
comes to writing for both humans and computers. What's the point
of having a high level language when you are only allowed identifiers
that the most simplistic mechanical interpreter can "understand"?

Why is it that programmers become somewhat irrational and
impractical when it comes to character sets? They do try to devise
all kinds of pattern recognition algorithms, tricky transformations,
get the best out of fuzzy measurement procedures, and so on.
But not so with character sets. No no, every school child knows
that characters must be such and such ... (maybe the early exposition
to characters is to be held accountable here, everyone is an expert :-)

Anyway, do we have some data that we could discuss that would
explain the practical importance of Unicode/casing issues?
Or, do we have programmers who are well versed in
using a keyboard connected to a computer and still can't
write a program that can tell apple characters from orange
characters?

GNAT already supports the detection of identifiers that were 
spelled similarly. In case of errors, it lists their "relatives".
Surely a helpful feature, and a proof that practical handling of
natural language identifiers is possible.
As an example, as you have been referring to German, consider that
sharp s, 'ß', is usually written "SS" when capitalized.
So "Straße" tends to become "STRASSE". Now if you have a composite
word that has
- a 'ß', and
- an 's' right after it,
such as "Maßstab" (= scale, rule, yardstick), then from a simple
minded formalist's perspective I could argue:

  "Using Unicode is nonsense because there is no 1:1 mapping for the
  German word 'Maßstab' which will become 'MASSSTAB'. "SSS" is
  ambiguous, it could be "sß" or it could be "ßs". That's too big
  a challenge for a compiler write. So leave me alone with your
  Unicode and case insensitivity."

Is that what computer science has to answer when asked about
characters handling?

Challenge: Try to find a significant number of German words that
have an 's' before a 'ß'. What's the consequence of your findings?
Even if there are ambiguities in other languages, ambiguities are
not new to Ada (and C++, IIRC), and they have been addressed.

(It seems that the introduction of Unicode to Scheme 6 has recently
made Lisp case sensitive based on arguments such as the one above.
To me this shows "practicality" on the part of the language designer,
vulgo just compiler writer's laziness.)


If the programmers' representatives (the ARG for example) agree that
it is practical to exclude some casing rules or "representation rules",
such as "ue" <-> 'ü', I'm perfectly happy. Because the rule *is*
practical, it helps work, and to hell with mathematical fancies and game
theoretic character shuffling possibilities, when they do not
really matter.

>  What about parsing the source right to left, or top to bottom?

The writing direction problem is solved. Similarly, it seems possible
and practical to connect big endian and little endian computers,
and have them cooperate using algorithms. Both exist, as do apples
oranges, bananas, and pineapples. We can make nice fruit salads.