[Allegro] Kategorie-Wh-Zeichen ";"

[Thomas Berger]

Lieber Herr Oberfell,

> folgendes Phänomen tritt auf, wenn ein 3-stelliges Kategorienschema verwendet
> wird und als Wiederholungszeichen das ";" (Semikolon) vorkommt. Beim Demosystem
> ist alles in Ordnung.
> 
> Ein Beispiel zur Illustration:
> 
> var |abcdef|

auf das Problem hier hat Herr Allers ja schon hingewiesen


> ins #300;
> wri "300 = " #300; n n
> 
> Ergebnis:
> 300 = ef|
> 
> d. h. es fehlen die ersten 5 Zeichen (inkl. dem senkrechten Strich).

'n n' ist - zumindest nach dem Einkopieren eine Mail - ein schlechter
Test darauf, ob im write-Statement das #300; ein Problem darstellt,
aber weil ja ueberhaupt etwas ausgegeben wird, scheint es in Ordnung
zu sein (als Gegenprobe muesste man schauen, ob nicht alles in
Wirklichkeit in #300 statt in #300; gelandet ist).

Insgesamt ist ein nacktes ";" stets problematisch, sei es als
Folgezeichen in #300; oder in einer Registerangabe |; fuer find
oder qrix. Ich meine mich zu erinnern, dass es etwas entschaerft
wird dadurch, dass ";" nur (in gewissen Kontexten ueberhaupt Trenner
ist, wie Herr Eversberg angemerkt hat) dann Trenner ist, wenn *kein*
Leerzeichen vorangeht oder folgt. Das ist natuerlich ziemlich
unintuitiv.

Mittelfristig muesste Flex/Job die Anweisungen wohl genauer parsen,
d.h. ein ";" ist normalerweise illegal oder legal als Bestandteil
der *Flex*-Syntax und nur in genau benannten Faellen wie hinter #...
oder "|" ist es kein Syntax- sondern ein Datenelement. Ich weiss
aber gar nicht, ob man ueberhaupt einen so exakten Parser bauen kann,
oder ob immer irgendwo ambivalente Konstrukte ueberleben werden.

Ganz langfristig muss man sich ueber die Notation von Folgekategorien
Gedanken machen, historisch gab es schon immer mal Aerger, weil zunaechst
alle *Zeichen* erlaubt waren, dann aber ("~", ".", "ú" und noch einige
andere) immer mehr eine Steuerbedeutung bekamen und retrospektiv
verboten werden mussten. Aktuell sind diese Bytes in ihrer Doppelfunktion
als Zeichen und Folgekategorienzaehlung der Knackpunkt, der eine
vernuenftige Migration der internen Datenhaltung nach Unicode behindert,
das wird sich auch nicht von alleine loesen.

viele Gruesse
Thomas Berger