[Allegro] Kategorie-Wh-Zeichen ";"

[Thomas Berger]

Lieber Herr Eversberg,

>> Das, was Sie mit 'var' in die interne Variable (iV) schieben wollen, muß mit
>> Hochkommata eingeschlossen
>> werden; Sie müssen also
>> var "|abcdef|"
>> schreiben.
>>
> Das bringt auch nichts, eben getestet. Nein, bei acon ist der | ebenso
> ein Zeichen, von der Wirkung her, wie " und '. Das wurde eingeführt,

oh ja, in xcstring.rtf ist es dokumentiert, also wohl auch fuer a99.

Das heisst aber, dass das "|" in der Ausgabe nie haette sichtbar sein
duerfen und bereits das "var" irgendein Problem hatte im Beispiel von
Herrn Oberfell.


> als sich zeigte, daß man da noch so etwas braucht, und zwar wird es bei
> der Übermittlung von Formulardaten an acon in PHPAC eingesetzt. Da
> kann's ja sein, daß im einen Feld ' vorkommt und im andern ", vor allem
> in dem Sammel-Eingabefeld. Ist aber auch nicht wirklich eine Lösung,
> denn auch | kann vorkommen und kommt auch vor, nämlich in N-Daten.
> 
> Wir nehmen uns das nochmal vor...

Mein Standpunkt: Es geht nicht mit Hase-und-Igel-spielen, sondern nur
durch einen Escape-Mechanismus. "Es" ist dabei die Anforderung,
Zeichenketten irgendwo hin praktizieren zu wollen. Stellenweise versucht
es allegro (etwa bei den ganz alten Konstrukten qrix und find in der
Flex-Sprache) ja sogar noch ganz ohne Quotierungszeichen, das bringt
dann aber stets Probleme mit der Ende-Erkennung (etwa die frueher notorischen
Probleme beim Serienregister in WWW-OPACs, wo " ; " Bestandteil des
Suchbegriffs wird). In _..._-Ersetzungen hat es bereits vor 20 Jahren
Ansaetze gegeben, da ist \nnn ein Escape, irgendwie habe ich das aber
nie zum Funktionieren bringen koennen. Die Kroete ist natuerlich, dass
man bei Sichtung des ersten " nicht stur alles bis zum naechsten "
einlesen kann und dann alles hat, evtl. ist dieses naechste " ein
escaptes, so dass man gezwungen ist, eine Stelle zurueckzulesen um
zu schauen, ob dort das Escape-Zeichen steht, man also ein escaptes "
erwischt hat. Das reicht aber immer noch nicht, denn man muss zuerst
entscheiden, ob es sich um ein selbst wiederum escaptes Escape-Zeichen
gehandelt hat, das " also in Wirklichkeit doch nicht escaped war...
Aber ueberall sonst in der Datenverarbeitung hat man sich irgendwann
diesem Problem stellen und es sauber loesen muessen, oft z.B. indem
die Aufgabe auf einen Automaten uebertragen wird, der als Wechselspiel
zwischen "Tokenizer" und eigentlichem "Parser" implementiert ist
(lex and yacc come to mind).

Verschaerft wird das Problem uebrigens durch Steuerzeichen *in* den
quotierten Zeichenketten, man darf ja z.B. b"]" schreiben, muss aber
b"[[]" nehmen, wenn man b"[" meint. Und fuer ein gemeintes b"[a"
gibt es gar keine Loesung bzw. man muss durch geeignete Ersetzungen
die Zeichenkette trickreich vor- und nachbehandeln, damit das
syntaktische Nadeloehr passierbar bleibt. Das macht alles esoterischer
und fehlertraechtiger als es eigentlich sein muesste.

Natuerlich ist auch hier die alte allegro-Idee am Werk, dass dem Anwender
nichts kompliziertes zugemutet werden darf und er einfach das
Hinschreiben soll, was er meint, also z.B. den Suchbefehl

find |5 or atorium ; 5 or var |; mess?

aber gerade dem Bibliothekar muesste vermittelbar sein, dass man
irgendeine Form von Formalismus benoetigt, wenn man Text und
Subtext klar voneinander unterscheiden will (und dass man das wollen
sollte, weil es ansonsten zu Doppeldeutigkeiten kommen muss, sollte
er auch lernen koennen)

viele Gruesse
Thomas Berger