[Tustep-Liste] Formatiere-Steuerzeichen

Mi Mär 26 19:18:49 CET 2003

Lieber Peter,

Deine Frage an die TUSTEP-Liste war:

> seit langem habe ich wieder einmal eine Tue-Datei erstellt, um
> einen Text formatieren zu können. In der Beschreibung ist mir
> dabei aufgefallen, dass die Steueranweisungen $n und $$$n nicht
> mehr erwähnt werden, sondern nur noch &!n und &?n. 
> 
> Mir ist schon klar, dass dies mit der Möglichkeit, Steuermakros
> zu definieren zusammenhängt. Wenn ich allerdings keine Makros
> verwende, funktionieren $n und $$$n immer noch. Es wäre deshalb
> wünschenswert, wenn diese Befehle auch noch in der Beschreibung zu
> finden wären. Denn &!n und &?n sind nun wirklich keine
> brauchbare Alternative, weil z.B. &?1 mit dem voreingestellten
> Namen für einen Platzhalter, nämlich ?1, zusammenfällt.
> Das aber kann nur umgangen werden, wenn man als Kennung dafür
> beispielsweise ein Ausrufezeichen nimmt, was dann aber 
> dann mit dem Steuerbefehl &!n kollidiert.
> 
> Zudem hat dieses Verfahren den großen Nachteil, dass schon
> beim Aufruf einer Tue-Datei mit Formatiere-Parametern die
> Kennung für Platzhalter geändert werden muss, damit derartige
> Steuerbefehle richtig interpretiert werden. Einer Tue-Datei
> kann ich aber von außen nicht ansehen, was in ihr drin steckt.
> 
> Deshalb habe ich folgende Bitte: $n und $$$n sollten wieder in
> die Beschreibung kommen.
> 
> Und statt &?n sollte beispielsweise &~n möglich sein bzw.
> für &!n könnte man &\n vorsehen. 
> 
> Oder seh ich das völlig falsch? Und es gibt einen ganz
> anderen Ausweg aus diesem Problem.

Damit ist ein - wie ich meine - grundsaetzliches Problem
des Umgangs mit TUSTEP und TUE-Prozeduren angesprochen.

Zunaechst: Ich selbst war mit den 'neuen' FO-Makros (sie sind
ja gar nicht mehr neu, haben vielmehr schon etliche Jahre auf
dem Buckel) auch nicht gluecklich, und zwar i.w. aus denselben
Gruenden wie Du. Und wenn's schnell gehen soll, verwende ich
auch heute noch im Text '$n' und '$$$n' (aber das muss unter
uns bleiben).
   Aber es ist auch bei einem Programmsystem wie TUSTEP, das
sich selbst treu bleiben will, unvermeidlich, dass Innovatio-
nen irgendwann einmal mit bewaehrten alten Funktionen in Kon-
flikt geraten. Das Gesetz der Evolution verlangt dann, dass
das Alte dem Neuen Platz macht. Ueber die Anweisungen '&?n'
und '&!n' kann man in der Tat streiten, und ich denke, dass
H. Schaelkle aus den von Dir genannten Gruenden sich heute
wohl auch fuer eine anderen Namensgebung entscheiden wuerde.
Aber diese Aenderung jetzt durchzufuehren, nachdem '&!?n' und
'&!n' schon so viele Jahre im Gebrauch sind, ist ein folgen-
schwerer Schritt, den man nicht ohne weiteres, jedenfalls 
nicht ohne zwingende Gruende, tun sollte.
   Bei dem von Dir genannten Grund (dass naemlich das '?n' in
der Anweiung '&?n' mit der Kennung fuer Platzhalter '?n' kol-
lidiert) sollte man sich vergegenwaertigen, dass es gleich
mehrere Gruende gibt, auf diese Platzhalter heute nach Moeg-
lichkeit zu verzichten:
   Du sagst ja selbst, dass man einer TUE-Prozedur von aussen
nicht ansieht, was in ihr drinsteckt. Wenn mehrere Platzhalter
'?1', '?2' usw. verwendet werden, weiss der Anwender erfahrungs-
gemaess nach kurzer Zeit schon nicht mehr, welcher Platzhalter
wofuer steht. Wenn es bei den Platzhaltern bloss um Dateinamen
u.dgl. geht, steht deshalb in meinen TUE-Prozeduren im Kopf
beispielsweise ein kleiner Abschnitt mit Deklarationen, der
mir schnell ueber die verwendeten Variablen und deren Belegung
Auskunft gibt, und in der Prozedur werden die Variablen dann
(eingeschlossen in spitzen Klammern) verwendet. Zum Beispiel:
   #de,,*
   TXT = Sammelband.TXT
   FNT = Sammelband.FNT
   PSD = Sammelband.PS
   SCH = Schriften.XYZ
   GRA = Sammelband.GRA
   *eof
   #an,,<TXT>'<FNT>'<SCH>'<GRA>
   #da,<PSD>,sdf-ap
   #sa,<TXT>,.....,SCH=<SCH>
   <usw.>
Es ist wesentlich einfacher und weniger fehleranfaellig,
solche Variablen an EINER Stelle der Prozedur (am besten
natuerlich in ihrem Kopf) einzutragen, als sie ins TUE-
Kommando einzutippen.
  Freilich haben sowohl dieses Verfahren wie auch das der
Platzhalter einige Schwaechen. Die mit #de,,* definierten
Variablen funktionieren nur auf der Kommandoebene, nicht
auf der Parameterebene. (Das ist ein SEHR alter Wunsch von
mir an die Programmautoren, diese Einschraenkung aufzu-
heben ;o)) Man koennte also beispielsweise damit NICHT
den Text eines Kolumnentitels definieren und in den FO-
Parameter KT einsetzen. Wollte man diesen 'Inhalt' des
Parameters KT mit #TUE,...,pa=____ an die Prozedur ueber-
geben, so geht das auch nur mit der (durchaus erheblichen)
Einschraenkung, dass KEIN Spatium in der Formulierung des
Kolumnentitels vorkommen darf. So recht ueberzeugend ist
das also auch nicht.

Aber es gibt m.E. dennoch eine wirklich gute Loesung da-
fuer, naemlich die der Kommandomakros. Nein, ich rede jetzt
nicht davon, dass die Kommandmakros in den letzten Jahren
schier unglaublich an Funktionalitaet zugelegt haben und
dass man sich doch bitteschoen in diese neuen Funktionen
einarbeiten sollte. Sondern ich rede davon, dass auch
derjenige Kommandomakros verwenden kann, der kaum Ahnung
davon hat.
  Um es zu exemplifizieren: Eine TUE-Prozedur der von Dir
verwendeten Art (mit dem Namen FORMAT.PRG) koennte etwa so
aussehen:
   #an,,?1
   #fo,?1,...,*
   drt       ?2
   kt        |#/+?3#/-@/xxx|
   *eof
Aufrufen wird man die Prozedur dann etwa mit
   #t,format.prg,pa=sammelband.txt'ps-10'Kopftext

Ein funktionsgleiches Kommandomakro aber ist nur unwesent-
lich groesser:
   $$! QUELLE, TYP, KOLT
   $$= $ { }
   #an,,
   #fo,{QUELLE},...,*
   drt       {TYP}
   kt        |#/+{KOLT}#/-@/xxx|
   *eof
wobei in der ersten Zeile einfach die verwendeten Variablen
deklariert und in der zweiten Zeile die geschweiften Klammern
{...} als Variablenkennung definiert werden. Wenn dieses
Makro in einer Makrodatei unter dem Segmentnamen FORMAT ab-
gespeichert ist, wird es aufgerufen mit
   #$format,sammelband.txt,ps-10,Kopftext

Von der Benutzung her hat sich also kaum etwas geaendert.
Aber schon aus der Sicht des Programmiereres hat dieses
Verfahren den erheblichen Vorteil, dass in der Routine
selbst die Variablen mit 'sprechenden' Namen (statt der
nichtssagenden Platzhalter '?1', '?2' usw.) belegt sind.
Es kommen etliche Vorteile hinzu, unter anderem fallen die
oben skizzierten Einschraenkungen und Probleme weg. Weitere
Vorteile (dass man beispielsweise falsche und fehlenden An-
gaben des Benutzers ueberpruefen und ggf. nachfordern kann)
seien hier nur angedeutet. Und all dem steht bloss ein mini-
maler zusaetzlicher Schreibaufwand in der Prozedur als
kleiner Nachteil gegenueber - und den halte ich nun wirk-
lich fuer vernachlaessigbar.

Aus diesen Gruenden wuerde ich heute (obwohl ich mit Dei-
nem Standpunkt sympathisiere) fuer die Beibehaltung des
Status quo plaedieren und eher empfehlen, die kleine Um-
stellung der eigenen Prozeduren auf Kommandomakros vor-
zunehmen.

Es wuerde mich interessieren zu erfahren, wie andere dar-
ueber denken. Ueber Rueckmeldungen und Diskussionsbei-
traege zum Thema wuerde ich mich freuen.

Ganz nebenbei sei noch darauf hingewiesen, dass es in
FORMATIERE auch schon seit Jahren die Moeglichkeit gibt,
Spitzklammernmakros '<...>' zu definieren und zu ver-
wenden. Und da ich schon seit vielen Jahren aus voller
Ueberzeugung die Abkehr von jeglicher harten Formatie-
rung predige und statt dessen die Verwendung der sach-
lichen Auszeichnung (fuer die besagte Spitzklammermakros
nach dem bewaherten Vorbild von HTML und XML bestens ge-
eignet sind) nahelege, will ich an die damit verbundenen
Vorteile und Chancen (der Plattformunabhaengigkeit, der
Portierbarkeit und der Konservierbarkeit der Daten) mit
Nachdruck erinnern.

Viele Gruesse reihum von

Michael Trauth

---------------------------------------------------------------
Dr. Michael Trauth                  e-mail: trauth at uni-trier.de
Rechenzentrum                       office: Tel. 0651-201-3413
der Universitaet                            Fax  0651-201-3921
Universitaetsring                secretary: Tel. 0651-201-3417
D-54286 Trier
---------------------------------------------------------------