Vb.74b: "avanti" weiter verbessert

[Bernhard Eversberg]

Verlautbarung 74b der Entwicklungsabteilung                      960812
-------------------------------------------

Letzte substantielle Aenderungen vor Festschreibung von Version 1.0
-------------------------------------------------------------------

Die Beta-Phase soll in Kuerze beendet sein. Das bedeutet: die "avanti"-
Sprache wird auf dem dann dokumentierten Stand festgeschrieben. Noch ist
nirgends ein Routinebetrieb mit dem Server angelaufen. Nach Festschreibung
wird dies jedoch geschehen, und dann sind Eingriffe kaum noch moeglich.
Expertenmeinungen, die nach der Bekanntgabe vor zwei Wochen geaeussert
wurden, haben ein paar recht tiefe Eingriffe mit nicht geringem Programmier-
aufwand veranlasst.


Aenderungen der allgemeinen Regeln
----------------------------------
Zwei substantielle Aenderungen wurden noch an den allgemeinen Sprach-
regeln vorgenommen, und zwar aus zwei Ueberlegungen heraus:

-  Von der Intention her soll die "avanti"-Auftragssprache einen viel
   weiteren Kreis als den der "allegrologen" ansprechen. Deshalb sollte
   es keine Regeln geben, die in Computerkreisen als ausgefallen, eigen-
   willig, gewoehnungsbeduerftig oder gar verschroben empfunden wuerden. 
   (Die Eigenheiten der Export- und Importsprachen ergeben sich aus einem 
   gewissen Zwang zu Knappheit und Effizienz, der fuer "avanti" nicht 
   so sehr ins Gewicht faellt.)

-  Wenn man versucht, moeglichst viel Aehnlichkeit herzustellen zwischen
   zwei doch sehr verschiedenen Konstrukten mit sehr verschiedenen Aufgaben,
   kann das auch zu aergerlichen Fehlern durch Verwechslungen fuehren,
   weil man gedanklich dazu neigt, einmal Gelerntes zu uebertragen.
   Das kann kaum passieren: die "avanti"-Sprache hat nur noch sehr wenig
   Aehnlichkeit mit den anderen "allegro"-Sprachkonstrukten.

Wegen mancher Unterschiede werden wir uns die Kritik von "allegrologen"
zuziehen, da machen wir uns nichts vor. Andererseits hat die jahrelange
Erfahrung zweifelsfrei gezeigt, dass gerade die Exportsprache nicht von
jedem erlernbar ist, aus welchen Gruenden auch immer, und als kryptisch
empfunden wird. Weil hier nun eine Sprache ganz neu zu entwickeln war,
wurde die Chance genutzt, einen ganz anderen Entwurf zu wagen, der auf
mehr Akzeptanz hoffen darf. Laengerfristig wird es dann vielleicht so
sein, dass immer mehr Aufgaben der Exportsprache von dieser neuen
Jobsprache uebernommen werden koennen.

Die allgemeinen Aenderungen sind diese:

1. Kommentare sind stets mit // (Doppelschraegstrich) einzuleiten und duerfen
   nun ueberall stehen. (Das ist die Konvention von C++ und JAVA)
   Konsequenz: man kann Befehle auch einruecken; Leerzeichen am Zeilen-
   anfang werden ignoriert, d.h. die Zeile gilt dennoch als Befehlszeile!
   (Zeile "auskommentieren": // an den Anfang setzen.)
   Mehrfach-Leerzeichen waren ja schon erlaubt, d.h. die optische
   Gliederung eines "avanti"-Programms kann nach Belieben erfolgen.
   Tabulatorzeichen sind jetzt auch erlaubt, werden aber nicht empfohlen.

2. Es koennen mehrere Befehle in einer Zeile stehen. Als Trennung ist ein
   ';' dazwischenzusetzen.

An einzelnen Befehlen wurden auch noch Aenderungen und Erweiterungen
vorgenommen:

"if"-Logik geaendert
------------------
Gleichfalls zu eigenwillig erschien die Regel, dass bei zutreffender Bedin-
gung einer if-Anweisung die naechste Zeile auszufuehren sei oder aber, falls
hinter der if-Anweisung eine Sprungmarke stuende, zu dieser zu springen sei.

Die neue Regelung ist viel einfacher und plausibler :

Wenn die if-Bedingung zutrifft, wird der Rest der Zeile ausgefuehrt.

Das ist alles. Der "Rest der Zeile" kann aber nunmehr aus mehreren Anwei-
sungen bestehen, getrennt durch ';'. Es kann dort auch ein Sprungbefehl 
stehen, aber dann MUSS das Wort "jump" davor stehen, oder "j".
Eine "else"-Anweisung gibt es vorerst nicht. Statt
   if error anweisungA
   else anweisungB
kann man schreiben:
   if error anweisungA ; jump A
   anweisungB 
   A:
Sehr viel umstaendlicher ist das nicht, oder was denken Sie?
WENN eines Tages "else" eingefuehrt wird, werden Konstrukte dieser Art
natuerlich weiter funktionieren. Wir koennen das also ohne Bedenken
aufschieben.

Neue "if"-Bedingung
-------------------

if #nnn <bef>   Wenn #nnn im aktuellen Satz vorkommt, <bef> ausfuehren
                (<bef> kann eine beliebige Befehlsfolge sein)

"write"-Befehl verbessert
-------------------------
Jetzt koennen in einem "write"-Befehl alle Elemente beliebig und mehrfach
kombiniert werden, die hinter "write" erlaubt sind. Beispiel:

w n "Impressum: " #74  " : " #75 ", " #76 ". - " #77 n

Dann erscheinen die Kategorien #74, #75, #76 und #77 auf einer eigenen
Zeile hintereinander, getrennt durch die angegebene Interpunktion.
('n' steht fuer "newline" und kann auch ausgeschrieben werden.)
Achtung: zwischen den einzelnen Teilen kein Semikolon, nur Leerzeichen!
(Denn ; wuerde ja einen neuen Befehl einleiten)

Auch die Kombination von if und write ist moeglich:

if #22 write n "Einheitstitel: " #22 "." n 

Hiermit wird die Kategorie #22 auf eigener Zeile ausgegeben, mit
"Einheitstitel: " davor, aber nur wenn sie belegt ist - sonst wird
die Zeile uebergangen.

Nicht zu frueh freuen: die Moeglichkeiten der Exportsprache hinsichtlich
Manipulation der Kategorieinhalte und bedingter Bearbeitungen sind damit
noch lange nicht erreicht! Ein automatischer Zeilenumbruch findet hier
ebenfalls nicht statt.
(Warum kann man nicht "einfach" in der Jobdatei ganz normale Export-
befehle mit einbauen? Nun, das zu realisieren waere leider NICHT einfach.)

Die Update-Funktionen wurden eingebaut
--------------------------------------
Der Server kann jetzt eine Datei im Externformat (exportiert mit e-w.apr)
mit denselben Modalitaeten wie das bisherige UPDATE einmischen. 
Die Modalitaeten muss man vorher mit dem "set u"- Befehl setzen, und
zwar so wie bisher mit der Option -fmxy bei UPDATE:
Wenn z.B.  neu.dat  die Datei ist:

set u41               statt  update -fm41
update neu.dat

Das Wort "update" muss (aus Sicherheitsgruenden) vollstaendig geschrieben
werden, "upload" dagegen nicht. "upload" ist ein Spezialfall von "update",
und zwar wuerde "update" mit "set u01" dasselbe tun: Datensaetze alle als
neue Saetze behandeln, ohne Ruecksicht auf den Primaerschluessel.

Hinweis:
--------

Die Parameter e-w.apr muessen fuer andere Kategoriesysteme geringfuegig
angepasst werden:
In den folgenden zwei Zeilen:

#00 +A e0 #zz 0    wenn #00 vorhanden, -> #-A

#t{ "#00" C }      leere #00 ergaenzen, wenn keine vorhanden
                   (notwendig fuer Ladeschnittstelle von VPW)

muss man #00 ersetzen durch die erste Kategorie, die in der CFG definiert
ist, und zwar unmittelbar nach #u1 und #u2, die immer am Anfang stehen
muessen. Bei A.CFG ist das die #00, bei P.CFG (Pica) ist es #0100, bei
anderen muss man nachsehen, was es ist.


Freigabe
--------
erfolgt, sobald die update-Funktionen ausgetestet sind. Es sollen zuerst
noch Tests mit nicht zu kleinen Datenmengen gemacht werden und hinterher
soll Sniffer untersuchen, ob dabei auch nichts kaputtgegangen ist.
Das braucht noch etwas Zeit, vielleicht bis Mittwoch.

MfG  B.E.