[Tustep-Liste] TUSTEP erweitern, vereinfachen

[leic2501 at uni-trier.de]

Liebe Listenleser,

Herrn Stahls Problem hätte ich zunächst ebenso zu lösen versucht wie Herr
Trauth, kann aber das Argument, daß dafür die Struktur der Daten und vor allem
die Anzahl der Abschnitte bekannt sein muß nur allzu gut verstehen; ganz
abgesehen davon, daß ab spätestens 10 Abschnitten/Ausgabedateien bei Kopiere ja
Schluß ist. Natürlich könnte man ein eigenes kleines #Kopiere schreiben, das
die Daten zuerst nur analysiert und daraus das #Kopiere erstellt, das sie dann
aufteilt, und vermutlich wäre es auch möglich, die Anzahl der möglichen
Zieldateien für #Kopiere zu erhöhen, aber irgendwie scheint mir das keine
wirklich saubere Lösung zu sein. Ich vermute, daß für diese Art der
Problemstellung #Kopiere ganz einfach nicht das geeignete Werkzeug ist.
Ich fabuliere mit dem folgenden einfach einmal ins Blaue; wo ich mich irre,
bitte ich darum, korrigiert zu werden:
#Kopiere ist zuerst einmal dafür konzipiert, genau das zu tun, was der Name
sagt: eine Datei in eine andere zu kopieren und "unterwegs" bestimmte, vorher
in der Parameterdatei festgelegte Operationen vorzunehmen. Die Betonung liegt
hierbei auf "vorher festgelegt", d.h. die verarbeiteten Daten können den
Programmablauf nur beschränkt beeinflussen. Dazu gehört auch, daß es meines
Wissens auch nicht möglich ist mittels der verarbeiteten Daten die
Parameterdatei selbst zu beeinflussen. (Ich hätte mir z.B. schon häufiger
gewünscht, daß man in der Parameterdatei anstelle von Strings, also z.B.
Parametern der Gruppe X, Variablen verwenden kann, die erst während des
Programmablaufes beschrieben bzw. geändert werden.) Es ist also beispielsweise
nicht möglich, "dynamisch", d.h. während der Laufzeit den Namen einer Zieldatei
anhand von Zeichenfolgen aus den verarbeiteten Daten zu ändern, was im o.g.
Problem wünschenswert wäre. Ich war versucht irgendwo (z.B. bei den
Rechenanweisungen) eine Anweisung vorzuschlagen, die dafür sorgt, daß für den
Namen der aktuellen Zieldatei während der Laufzeit der Arbeitstext eingesetzt
wird, bin aber davon abgekommen. Denn ich denke, immer dort, wo solche Probleme
auftauchen, ist man tatsächlich mit #Makro besser bedient als mit #Kopiere.
Vielleicht gilt das ja auch für Ihren Wunsch nach mehreren Merktexten, Herr
Sappler, die ja im Grunde nichts anderes als Variablen sind.
Um Mißverständnisse zu vermeiden: Wenn es mit vertretbarem Aufwand möglich ist,
einen oder mehrere weitere Merktexte oder gar Textvariablen für #Kopiere zu
ermöglichen, die sich dann vielleicht in bestimmte Parameter wie z.B. XX oder
ERG einbauen lassen, wäre das eine große Erleichterung und ich sehr dankbar
dafür, weil ich meist vergessen habe, was in einer vor einer Woche gebastelten
Sprungtabelle eigentlich passiert und es mir daher auch entgegenkäme, wenn man
sich zumindest die Sprünge, die man benötigt, um den Ersetzungstext als
Merktext zu "mißbrauchen", sparen könnte.

Einen anderen Wunsch bezüglich #Kopiere habe ich schon seit einiger Zeit: Es ist
ja dankenswerterweise ohne weiteres möglich, Zeichengruppen in Stringgruppen
einzubinden. Hat aber außer mir schon einmal jemand die Möglichkeit vermißt,
Stringgruppen in andere Stringgruppen einzusetzen? Ich möchte dazu ein kleines
Beispiel aus meiner Arbeit darstellen. Ich stand vor kurzem vor dem Problem in
einem Text anhand typographischer Merkmale Autor- und Werkssiglen zu finden und
auszuzeichnen. Solche Siglen sahen z.B. folgendermaßen aus:

#k+Schmidt#k-, #/+Die Erforschung der Nichtigkeit#/-, #k+II#k-, 12
#k+Müller#k-, #/+Transzendentale Metaphysik#/- cap. 4, 34ff.
#k+Buschmann#k- #/+Decepting people#/-, 2000#H:9#G:-2008#H:9#G:9
usw.

Formal beschreiben könnte man eine Sigle also mit:
#k+[Autor]#k-, #/+[Werk]#/-, [Referenz]

Die Referenz besteht dabei aus einer beliebigen Anzahl von Elementen, deren Kern
(der immer vorhanden sein muß) im Wesentlichen folgende Zeichenfolgen bilden:

#k+[röm. Zahl]#k-
<>>/

Hinter jedem der o.g. Elemente kann fakultativ ein Sufix in Form einer
hochgestellten Zahl, eines hochgestellten Kleinbuchstabens, "ff." "f.", o.ä.
stehen, davor ist ein Praefix, z.B.: "cap. ", "c. ", "s. " usw. möglich.
Ebenso kann es sein, daß ein Bereich angegeben ist, daß also zwei dieser
Elemente durch "-" getrennt vorkommen.

Außerdem kann nach jedem Leerzeichen in der Sigle ein Tag für Seitenumbruch
("{[Seitenzahl]}") stehen.

Schön fände ich es, wenn man das Problem ungefähr folgendermaßen lösen könnte:
        * Kleinbuchstaben und Zahlen
>0z       >*>/
        * röm. Ziffern
>1z       <I<V<X<L<C<D<M
        * alles, was zwischen #k+...#k- und #/+...#/- stehen darf
<0s       ||#k-|#/-||<%|
        * Seitenumbruch
<1s       |{<>>/}|
        * der "Kern" der Referenzelemente
<2s       |#k+<>>1#k-|<>>/|
        * fakultative Suffixe der Referenzelemente
<3s       |#H:>0#G:|ff.|f.|sq.|sqq.|
        * fakultative Praefixe der Referenzelemente
<4s       |cap. |c. |s. |nr. |no. |p. |pp. |
        * Beschreibung eines Elementes
<5s       |><<4<2><<3|><<4<2><<3-<2><<3|
        * Referenzelement + Blank u. Komma + Zeilenwechsel
<6s       |,><<1 <5|,><<1 <5-<5|

xx        |#k+<>>1#k-,><<1 #/+<><1#/-<><6|
xx       
|<<sig>>>=(1-3)<<au>>>=4<</au>>=(5-13)<<ti>>>=14<</ti>>>=(15-17)<<re>>>=18<</re>><</sig>>|


Bestimmt wäre es bei diesem (vereinfachten) Beispiel noch möglich, mehrere
Stringgruppen zu einer einzigen zusammenzufassen und in dieser dann alle
möglichen Kombinationen einzeln anzugeben, aber irgendwann wird das sehr mühsam
und dadurch, daß sich die Kombinationsmöglichkeiten ja multiplizieren auch
unübersichtilich und schwierig zu warten und zu erweitern, so daß ich zumindest
schnell dazu tendiere, "Flickschusterei" zu betreiben, während das Modell, das
man benutzen könnte, wenn Stringgruppen innerhalb anderer Stringgruppen möglich
wären, besser dazu geeignet wäre, das wirkliche Problem genau nachzubilden.
Vermutlich geht das momentan nicht, weil die Gefahr besteht, daß eine unendliche
Rekursion zustande kommt, wenn man z.B. Stringgruppe1 in Stringgruppe2 einsetzt
und Stringgruppe2 wiederum in Stringgruppe1. Daher wäre es vielleicht vonnöten,
einen neuen Typ Stringgruppen einzuführen, die hierarchisch geordnet sind und
bei dem sich nur Stringgruppen einer Ebene nur in übergeordnete Stringgruppen
einsetzen lassen.

Ich hoffe, ich habe mit diesem Beispiel niemanden verschreckt und möchte deshalb
alle, die schon vor ähnlichen Problemen standen, bitten, sich (evtl. mit
eigenen Beispielen) dazu zu äußern.

Bezüglich Ihres Lösungsvorschlags zu Herrn Stahls Problem, Herr Schälkle, hätte
ich noch eine Frage: Sie verwenden in Ihrem Beispiel die Funktion FILE, um den
Inhalt einer Datei in eine Sternvariable einzulesen. Das ist (oder war?) doch
aber nur bei kleineren Dateien möglich. Für große Dateien müßte man meines
Wissens mit der ACCESS-Anweising arbeiten. Da fand ich bisher immer mißlich,
daß es nur möglich war, auf strukturierte Daten zuzugreifen. Hat sich das
inzwischen geändert? In der Liste der Tustep-Neuerungen könnte ich leider
nichts dazu finden. Ein wirkliches Problem ist das nicht, denn es ist ja kein
großer Aufwand ein #Kopiere vorauszuschicken, das ganz einfach eine
entsprechende Kennung am Datensatzanfang ergänzt, aber gerade bei größeren
Dateien ist es ein wenig lästig.

Viele Grüße

Johannes Leicht

-----------------------------------------------------------------------
Diese Nachricht wurde mit dem Webmailer der Universitaet Trier erstellt