AW: [Allegro] Trick 31: FLEXe verschachteln

[Thomas Fischer]

Hallo Herr Allers,

herzlichen Dank für Ihre Antwort.
 
> > Den 
> > include-Befehl habe ich in meiner Dokumentation (v.26.8) zunächst 
> > nicht gefunden, weil er nicht in der alphabetischen Reihenfolge 
> > aufgeführt ist.
 
> Es handelt sich bei 'include' ja auch um keinen normalen 
> Flexbefehl, den man so ohne weiteres unter die Flexbefehle 
> alphabetisch einordnen könnte, sondern um das, was hier 
> "Texteinschlußbefehl" genannt wird und der deshalb etwas 
> außer der Reihe steht.

Na ja, in der Perl-Dokumentation findet man "use", "require", "import" wohl
als "Keyword", nicht als "Function" bezeichnet, aber in der normalen
alphabetischen Reihenfolge.
Ich würde alles, was auf einer Zeile in einer Flexdatei stehen kann, als
Flexbefehl (normal oder nicht) bezeichnen und so einordnen - wenn es ein
spezieller Befehl ist, kann man ja darauf hinweisen, sobald er gefunden ist.

> 
> Um solch Sachen zu finden, benutze ich oft und mit großem 
> Erfolg das Füllhorn, gehe dann auf "Letzte Neuerungen (ab 
> 2000)" und suche dann dort, hier also nach "include" - und 
> schon bin ich fündig!
> 
> 
> > Muss das so sein? 
> 
> 
> Ja, es kann nicht anders sein, bei den bekannten 
> Personalkapazitäten, die hinter Allegro stehen und bei dem 
> Komplexitäts- und Differenziertheitsgrad, den dieses 
> Programmsystem heute erreicht hat und der mit Hilfefunktionen 
> und Dokumentation versorgt sein will!

Das sehe ich teilweise auch so. Allerdings wird m.E. die Situation dadurch
unnötig verschärft, dass bei der Entwicklung der Skriptsprachen sehr
ungewöhnliche Konstrukte gebaut werden. Dadurch können Erfahrungen mit
anderen Skriptsprachen (z.B. Perl, JavaScript) nicht auf Flex, Export- und
Importsprache übertragen werden und es entsteht größerer Klärungsbedarf.

> 
> > > 2. Rückaufruf des ersten FLEXes
> > ...
> > >    zuerst die Variable #urC löschen!
> > > #urC
> > > ins #urC     // iV-Inhalt in #urC speichern
> > > var #urC     // pruefen, ob das mit "jump" anfaengt
> > > if "jump" var #urC(b"jump ");jump
> > > ...   // beliebiger Inhalt
> > > exec zweit.flx first;weiter
> > > :weiter
> > 
> > 1. Was bewirkt
> > #urC
> 
> 
> Die Anwendervariable wird leergefegt, mit dem zusätzlichen 
> Effekt, daß sie hinterher auch nicht mehr existiert; die 
> Flexbefehlabfolge

Das heißt, dass das, was bei jeder anderen Programmiersprache als
#urC = "xyz"
oder ähnlich ausgedrückt würde, in der Flexsprache als
#urC xyz
geschrieben wird. Lohnt sich diese Ersparnis wirklich?
Oder muss/kann es
#urCxyz
heißen, und wo finde ich das?

> > 2.
> > Meine Vorstellung ist:
> > ins #urC: iV in #urC schreiben
> > var #urC: #urC in iV schreiben
> > (Mir ist das Verhältnis von "interner Variabler" zu > dem 
> Allegro-Konzept des
> > Arbeitstexts nicht ganz klar.)
> 
> 
> Ich würde sagen, daß die Rolle, die der _Arbeitstext_ 
> im Bereich der klassischen Exportparametrierung 
> spielt, vergleichbar ist mit der, die die _interne 
> Variable_ (iV) in der Flexwelt spielt.

Ja, den Eindruck habe ich auch und würde das gerne explizit machen bzw.
irgendwo nachlesen, wo diese Analogie an ihre Grenzen stößt.

> 
> > So naiv interpretiert würde
> > ins #urC
> > var #urC
> > iV in #urC und #urC in iV schreiben.
> > Wofür ist das gut?
> 
> 
> 'ins #urC' ist gut dafür, den aktuellen Inhalt der iV 
> dauerhaft in der Anwendervariablen #urC 
> aufzubewahren und die iV frei für neue Besetzungen 
> zu haben.
> 
> 
> 'var #urC' schüttet den Inhalt der 
> Anwendervariablen #urC in die iV zurück.
> 
> 
> > Und was steht eigentlich nach dem insert-Befehl in der iV?
> 
> 
> Das Gleiche, was vorher drinstand - bis in die iV 
> etwas Neues hineingeschüttet wird (mit 'ins ...'). Der 
> schlichte Befehl 'ins #urC' ändert nichts am Inhalt 
> der iV.

Das hatte ich auch gedacht. Wenn aber #urC in der iV steht, dann kann
var #urC
doch nichts ändern, oder?

> > 3.
> > if "jump" var #urC(b"jump ");jump
> > bewirkt, dass zu <Marke> gesprungen wird, wenn die iV "jump <Marke>"
> > enthält.
> > Sollte da sicherheitshalber auf
> > if "jump "
> > geprüft werden, weil auch b"jump " benutzt wird?
> 
> 
> Das ist schnuppe; Sie _müssen_ nicht auf 'if "jump "' prüfen, 
> denn der Flexprogrammierer würde sich selbst ziemliche 
> Stolpersteine in den Weg legen, wenn er #urC mit "jumpstart" 
> besetzen würde.

Das sehe ich einerseits genauso, habe mir nach unangenehmen Erfahrungen in
komplizierten Exportparameterdateien aber zur Gewohnheit gemacht, Test (if
"jump ") und Aktion (b"jump ") immer mit denselben Zeichenketten
durchzuführen, weil doch sonst irgendwann Murphy's Law zuschlägt, typischer
Weise an einer weniger offensichtlichen Stelle.

 
> > 4. Was ist 
> > exec zweit.flx first;weiter
> > für eine Konstruktion? Das sieht
> > aus als würde das "first;weiter" in dem #urC von zweit.flx ankommen,
> 
> 
> Ja, so ist es. Die Zeichenfolge "first;weiter" wird via 
> Aufruf von zweit.flx dieser Flexdatei mitgegeben und ist dort 
> zu Beginn als Inhalt der iV verfügbar.
> 
> 
> > wieso?
> 
> 
> Die Möglichkeit der Übergabe von Zeichenfolgen beim Aufruf 
> von Flexdateien ist vor nicht sehr langer Zeit zur Freude von 
> vielen unter uns eingeführt worden. In der Dokumentation 
> steht's drin, aber ich habe die Stelle jetzt auf die Schnelle 
> auch nicht gefunden.  :-((

Finde ich ja auch gut, allerdings auch nicht so ungewöhnlich, dass man
Funktionen oder Prozesse mit Parametern aufrufen kann. Wie die Syntax dafür
aussieht, wüsste ich aber schon gerne. Das sieht auch so aus, das man nur
einen Parameter übertragen kann (es gibt ja auch nir eine iV).

Und bei der Betrachtung des Skriptes fällt jetzt auch auf, dass der Befehl
#urC
seine Besonderheit hat:
Während für die meisten Flex-Befehle, für die das Sinn ergibt, das Prinzip
gilt:
"Wenn der Parameter fehlt, wird der Inhalt der iV genommen." 
ist dies hier nicht der Fall.
(In dem Fall var gilt dies auch, ist mir in seiner Funktion aber
unverständlich:
var
ersetzt den Inhalt der iV durch iV? In den Worten der A99-Dokumentation:

"variable cstring
...
Fehlt cstring, wird statt dessen der Inhalt der iV interpretiert, d.h. es
entsteht daraus ein neuer Inhalt in der iV.")

Und noch etwas: Dass
#urC
ins #urC
geschrieben wird, heißt doch wohl dass erst #urC gelöscht wird, bevor der
Inhalt der iV hineingeschrieben wird. Warum wird das gemacht? In der Doku
steht:
"Inhalt der  internen Variablen  in die Kat. #xyz kopieren.
Ist die  iV  leer, wird die Kategorie gelöscht!"
Daraus würde ich schließen, dass nur
ins #urC
genau dieselbe Wirkung hätte.

Mit freundlichen Grüßen
Thomas Fischer