[Allegro] HFM : Neue Lösung, a99-Prototyp zum Testen

[Bernhard Eversberg]

                                                              2014-06-23
HFM : Neue Lösung
-----------------

Am Freitag war entschieden worden, sich nochmal "einen Kopf zu machen"
hinsichtlich der Hochfrequenz-Mehrfachfelder (HFM).
(Standard-Anwender sind von der Thematik nicht betroffen, sondern nur
jene, die bei einigen Feldern mehr als die bisher möglichen
Mehrfachbelegungen brauchen.)

Hiermit wird eine Lösung vorgelegt, die zunächst mehr oder weniger
prototypisch in a99 umgesetzt wurde, also realistisch ist.

   http://www.allegro-c.de/aktuelle-version/a99hfm.zip

[Der neue FTP-Service muß noch weiter verbessert werden ...]
Die ZIP-Datei enthält ein a99hfm.exe zum Ausprobieren.

Uns scheint nach tiefschürfender Beschäftigung mit der Materie die
hier beschriebene Lösung das Äußerste zu sein, was wir unter den
gegebenen Umständen und Randbedingungen realisieren können.
Bei Zustimmung versuchen wir uns, so schnell's eben geht, an einer
vollständigen Implementierung.
Bei substantiellen Bedenken oder Ablehnung nicht, dann bleibt's bei der
vorige Woche beschriebenen Kompromißlösung, die mit einem FLEX auskommt
und die Quellprogramme nicht ändert.

Zu den Details der Lösung:
(Am Ende unter ABER stehen drei noch nicht klappende Sachen)

o  Die bisher möglichen Mehrfachfeld-Kennungen bleiben voll erhalten,
    d.h. keine Änderungen bestehender Daten werden fällig.

o  Anwendungen arbeiten mit den neuen Programmen unbetroffen weiter,
    also auch keine Änderungen nötig in Parametern, FLEXen und Jobs.

o  Neu hinzu kommt eine mehrstellige Mehrfachkennung aus Ziffern, die
    wie folgt aussieht und auch in Altanwendungen ohne neue Vorkehrungen
    sofort anwendbar ist, und zwar bei jeder CFG ohne Änderung (!):
            #nn.zzz   (z.B. $a.cfg)
      bzw.  #nnn.zzz  (z.B. $n.cfg, $u.cfg)
      bzw.  #nnnn.zzz (z.B. $p.cfg)
    mit beliebigen Ziffern z, und zwar auch mehr als 3
    (Max. 5 werden empfohlen; mehr sind möglich - aber sinnvoll?)
    Nur Ziffern, also auch keine Dezimalzahlen! Die erste Nichtziffer
    ist dann das erste Zeichen des Feldinhalts.
    Dafür wird der neue Terminus  HFM-Feld  eingeführt.

o  Ältere Programme können damit nicht umgehen, sie lassen beim
    Einlesen eines derartigen Satzes nur das letzte Feld mit dem .
    übrig!

o  Wenn dem Punkt keine Ziffer folgt, wird er als normale Mehrfach-
    kennung behandelt - wie bisher! D.h. auch wo ein Punkt schon
    in den Daten verwendet wurde, ändert sich nichts.

o  Die neuen Kennungen werden im Datensatz unterhalb der bestehenden
    eingeordnet, also #nnn.1 unter #nnn.z, und zwar nach ihrem
    Zahlenwert, d.h. .10 folgt auf .9

o  Achtung: Zahlen nicht mit führenden Nullen schreiben, das ist
    sinnlos! Wenn man das tut, werden die weggenommen.

o  Die Zahlen müssen nicht lückenlos aufeinander folgen.
    Daher könnte man Nummern auch mit einer Semantik ausstatten.

o  Bei der Eingabe gilt:
    Hinter .zzz kann ein, muß aber kein Spatium stehen. Nur wenn der
    Inhalt des Feldes mit Ziffer beginnt, dann muß hinter .zzz ein
    Spatium stehen, das versteht sich von selbst. Ansonsten wird,
    wenn es fehlt, das Spatium automatisch ergänzt, d.h. gespeichert
    wird in jedem Fall mit Spatium.

o  Mit  var #nnn.zzz  ergibt sich stets der hinter .zzz stehende
    Inhalt, ohne das Spatium.

o  Auch  var "abc"\ins #nnn.zzz  ergibt stets  #nnn.zzz abc,
    also mit Spatium vor dem Inhalt.

o  Und ganz wie bei "normalen" Feldern:
    Bei Eingabe von  #nnn.zzz  ohne Text wird das betr. Feld beseitigt;
    ebenso im FLEX bei  var ""\ins #nnn.zzz

o  Mit  var #nnn~  erhält man in FLEX das letzte der Mehrfachfelder
    des Feldes #nnn - wie schon bisher

o  Wenn in der CFG bei der betr. Felddefinition eine Angabe $M steht,
    womit die zulässigen Mehrfachkennungen eingeschränkt werden, dann
    muß der Punkt hinter dem $M vorkommen, wenn er bei dem Feld
    verwendbar sein soll. (Versteht sich eigentlich von selbst)

o  In Parameterdateien kann man, wie bisher, ak=nnn."xyz"+B  schreiben,
    um alle Einzelfelder abzuarbeiten, also auch die mit .zzz

o  Ebenso ist  #nnn. ++ ...  möglich, um eine schleifenförmige
    Abarbeitung aller Mehrfachfelder zu erreichen; s. aber unter ABER!

o  Der FLEX-Befehl  var kr  bzw.  var kn  wirft die .-Felder
    alle mit aus.

o  Für den Hintergrundspeicher gilt die Neuerung zunächst nicht!
    Dort entstehen drei Mehrfachfelder mit . / 0, die sich zyklisch
    verschieben. (Das entspricht bisheriger Funktionsweise und ist
    vermutlich weder besonders nützlich noch überhaupt bekannt.)

o  Für die #u-Variablen gibt es keine Änderung, d.h. man kann nicht
    #uxy.1 und #uxy.123 usw. verwenden. Das macht, denken wir,
    nichts aus, denn es sind ja nur temporäre Variablen, und in
    FLEXen verwendet man eh lieber $- oder &-Variablen, die anderen
    Gesetzen folgen.

ABER:

-  Noch nicht funktionabel: Ein HFM-Feld in der Kategorieliste der
    Parameter direkt ansprechen, also z.B.
    #98.123 p"Feld 123" ..
    Dann kommt nur das erste von mehreren .-Feldern raus, samt Zahl,
    und bei
    #98. ++ ...
    kommen alle raus, jedoch gleichfalls MIT der Zahl am Anfang.
    Mit diesem Misfeature könnte man u.U. leben, die Realisierbarkeit
    wird aber noch geprüft.
    (Im Gegensatz dazu, aber ungleich wichtiger:
     ak=98.+X  und ak=98."..."+X  klappen korrekt )

-  In a99 geht noch nicht:  if #nnn.zzz
    Es ergibt sich stets "no", bei  var #77.  kommt aber das erste
    von mehreren #77 raus, und zwar auch, wenn es eine ohne . ist.
    Auch hiermit könnte man wohl leben, weil damit keine existierenden
    FLEXe betroffen sind, und für neue könnte man auch z.B. schreiben:
    var #77.zzz
    if not "" ...

-  Bei Eingabe von  #nnn.~ xyz  hätte man gerne folgendes noch nicht
    realisiertes Verhalten:
    Es wird die letzte #nnn.zzz gesucht und auf die Zahl dann 1
    aufaddiert, um die nachfolgende HFM-Kennung zu bilden.


B.E.