APL2

So steht es im APL2 User's Guide unter "Deviations from APL2 Programming Language Reference":

"Any usage of bracket indexing in a selective assignment expression, such as

(2↑V[⍳4])←3

gives SYNTAX ERROR."

Das hat bisher auch stets so "funktioniert". Ich konnte mich also darauf verlassen, dass vom Host migrierte Funktionen an solch einer inkompatiblen Stelle unterbrochen wurden.

Es ist allerdings nicht nur so, dass Workstation APL2 eine selektive Zuweisung kombiniert mit den eckigen Klammern nicht zulässt, es versäumt in einem Spezialfall sogar die oben beschriebene Fehlermeldung. Hier ist der Fall:

V←(1 2 3)(4 5 6)

(1⊃V)[2]←12

Keine Fehlermeldung, kein SYNTAX ERROR, wie doch im User's Guide angekündigt. Sollte es etwa möglich sein, dass mit "Pick" in einer selektiven Zuweisung die Nutzung von eckigen Klammern möglich wird?

Leider nicht. Die Verarbeitung wird zwar ohne Fehler fortgesetzt, aber im obigen Beispiel bleibt V unverändert, als wäre die betreffende Anweisung nicht vorhanden.

Es ist schon schade, dass diese Form der selektiven Zuweisung auf der Workstation nicht funktioniert (man kann die Inkompatibilität immerhin leicht mit Hilfe der Indexfunktion beheben). Es wäre allerdings hilfreich, wenn APL2 Workstation auf solche Stellen konsequent mit einem SYTAX ERROR reagiert.

... sollte man meinen.

Das könnte auch so sein, denn als Sprache enthält APL eine Vielzahl paralleler Konzepte. So kann die Addition zweier Matrizen auf mehrerer Prozessoren verteilt werden, ohne dass der Entwickler das explizit vorgeben muss. Dies gilt für viele Funktionen und Operatoren, es ist nur eine Frage der jeweiligen Implementierung.

Und genau hier scheitern die heutigen APL-Interpreter: Sie nutzen die inzwischen üblichen mehrfachen Prozessorkerne nicht für diese Art der Parallelität. Man kann nur hoffen, dass die Entwickler von APL-Systemen die Chance, die moderne Prozessorarchitekturen bieten, nutzen werden. APL als Sprache ist dafür bestens geeignet, besser als die meisten anderen Sprachen.

APL2 macht mit der CSD 12 einen ersten Schritt in diese Richtung. Mit den definierten Operatoren PEACHT und PEACHP werden Modelle für ein paralleles "Each" angeboten.

Auch mit APL2 Service Level 12 gilt, was bereits für vorangehende Versionen angemerkt wurde:

• APL-Zeichen wie z.B. "∆" in Namen von APL2-Objekten werden in der Titelleiste des Objekteditors nicht als solche angezeigt - soweit man den Schicki-Micki Aero-Desktop verwendet.
  
  Die Korrektur ist wohl schwieriger als man erwarten sollte. Microsoft legt den APL2-Entwicklern (und nicht nur denen) auch schwere Steine in den Weg.
  


• Bei deaktivierter Benutzerkontensteuerung entfällt die Einschränkung in der readmec.txt bezüglich des Zugriifes auf Dateien im APL2-Installationsverzeichnis.
  

Was ist das? P15 in Aktion!

Alle beteiligten Variablen sind mit dem neuen Prozessor 15 - "Access Structured Storage" - assoziiert. Dies geschah natürlich bevor der Wert der Variablen erstmalig abgefragt wurde:

 'J16 0' 15 ⎕NA 'A'

 ('ADDRESS' 'A')15 ⎕NA 'ADR'

Die hier erstellte Variable ADR enthält die aktuelle Speicheradresse der Variablen J16. Als Name verweist "A" (und auch die folgenden Namen) auf Speicher außerhalb des APL-Workspaces.

Ursache: Ich verändere eine Variable, hier E8←123.456
Wirkung: Weitere Variablen werden ohne Einwirkung von außen modifiziert.

Bug or Feature?

Ein mögliches Szenario: Bei den beteiligten Variablen handelt es sich um "gemeinsame Variablen" zweier APL2-Sitzungen. Die weitere Sitzung reagiert auf die Veränderung der " Shared Variable" E8 und verändert die anderen gemeinsamen Variablen I4, I2, C1 und B1.

Das wäre leicht zu realisieren, es geht aber einfacher.

     E8

0

      I4

0 0

      ⎕AF C1

0 0 0 0 0 0 0 0

      8 8⍴B1

0 0 0 0 0 0 0 0

0 0 0 0 0 0 0 0

0 0 0 0 0 0 0 0

0 0 0 0 0 0 0 0

0 0 0 0 0 0 0 0

0 0 0 0 0 0 0 0

0 0 0 0 0 0 0 0

0 0 0 0 0 0 0 0

Keine Frage, alle Variablen sind irgendwie 0. Aber was passiert hier?

Eine der wesentlichen Neuerungen der CSD 12 betrifft die DB2-Schnittstelle:

"As of Service Level 12, AP 127 has been re-written to use the CLI interface to DB2."

Dahinter steckt eine große Erleichterung: Nie wieder muss ich APL2 an eine DB2-Datenbank binden bevor ich auf diese per AP127 zugreifen kann.

Aber Vista zerstört so manche Verbesserung: Nach Installation der CSD 12 funktionierte das Deklarieren einer gemeinsamen Variablen mit dem AP127 schlicht und ergreifend nicht. Jeder Versuch brachte nur einen Kopplungsgrad von 1, einen zuwenig, um mit dem AP127 sprechen zu können.

Und wer stand wohl zwischen APL2 und dem AP127? Wie so oft die Benutzerkontensteuerung. Erst nachdem ich sie komplett ausgeschaltet hatte, konnte ich auf eine DB2-Datenbank zugreifen.

Netter Nebeneffekt: Bein Starten von Vista taucht nebenstehende DB2-Fehlermeldung nicht mehr auf und mit DB2 lässt sich wieder so bequem arbeiten wie unter XP.

Aber das ist nicht der einzige Grund, die Benutzerkontensteuerung entgegen der Empfehlung von Mickeysoft auszuschalten.

Zu den Neuerungen des Service Level 12 gehört mit dem P15 ein neuer Assoziierter Prozessor. Auf den ersten Blick ähnelt er konzeptionell dem P12 "Files as Variables", nur dass hier nicht Dateien wie APL-Variablen behandelt werden, sondern Speicher außerhalb des APL2-Arbeitsbereiches.

Diese Neuerung ist für mich die große Überraschung und in ihrer Auswirkung auf das Arbeiten mit APL2 schwer einschätzbar.

Dagegen offenbart sich der Nutzen der folgenden Erweiterungen mehr oder weniger sofort:

Einen Monat früher, als ich erwartet habe ist die CSD 12 für Workstation APL2 verfügbar. Dass mit diesem Service Level die Ausführung von Stored Procedures durch den AP127 möglich wird oder ActiveX Steuerelemente für Dialoge genutzt werden können, war vorhersehbar. Beides bietet weite Felder für neue Anwendungen.

Daneben wartet die CSD 12 mit einer großen und vielen kleineren Überraschungen auf. Die vollständige Liste der Neuerungen findet man wie üblich in der readmec.txt im APL2-Installationsverzeichnis. Hier nur eine Auswahl, die Reihenfolge ist mehr oder weniger willkürlich:

Die meisten Abweichungen zwischen APL2 Versionen für den Mainframe und für Workstations führen bei Ausführung auf einer Workstation umgehend zu einem Fehler. Bei selektiven Zuweisungen wäre das z.B. ein SYNTAX ERROR. So ärgerlich das auch sein mag - vor allem, wenn sie zu Hunderten auftauchen - man kann die Inkompatibilität stante pede beheben. Die Diagnose liegt auf Hand, mit der Behandlung kann sofort begonnen werden.

Leider ist dies nicht immer der Fall. Die fehlende Füllfunktion für den Each-Operator ("No fill function is implemented for the Each operator") muss nicht zum sofortigen Abbruch der betroffenen Anweisung führen. Die Auswirkungen der Inkompatibilität können auch erst viel später in den unendlichen Tiefen einer komplexen Anwendung auftreten.

So geschehen mit

⍕¨NUM_ARRAY

Wie häufig ist das rechte Argument von Format hier numerisch, im vorliegenden Fall allerdings auch leer. Das Ergebnis ist natürlich (wegen "Each") wiederum eine leere Struktur, aber leider eine numerische und keine alphanumerische, wie vernünftigerweise zu erwarten wäre - und wie es APL2 Mainframe auch vorsieht.

Nicht ganz so lange kann der Test auf Identität jeweils zweier aufeinanderfolgender Zeichenketten in einem Vektor aus 1 Million solcher Elemente dauern. Allerding nur auf dem Mainframe und mit "N-wise Reduce":

2≡/VEC

So harmlos dieser Ausdruck auch aussieht, er hat es in sich. Für den vorliegenden Fall langer Vektoren VEC mit relativ kurzen Zeichenketten (z.B. mit Länge 10) als Elemente habe ich nicht die Geduld gehabt ein Ergebnis abzuwarten. Denn selbst eine Schlewife, in deraufeinanderfolgende Vektorelemente vergleichen werden, wäre schon lange mit dem Thema durch gewesen. Erst rech natürlich die typische APL-Lösung ohne N-wise Reduce, selbst bei mehr als 1 Million zu vergleichender Objekte.

Später habe ich erfahren, das dieser Ausdruck mit den Daten wie hier beschrieben auf einem IBM Mainframe nach ca. 38 Stunden mit dem Ergebnis rausrückte. Für einen heutigen Großrechner eine halbe Ewigkeit.

Ich hatte von Anfang an ein gute Gefühl bei REPLACEX, eine der wichtigen Neuerungen des APL2 Service Level 11 vom November letzten Jahres. Im ICE von Hamburg nach Berlin hatte ich vor der GSE Herbsttagung 2007 Gelegenheit, REPLACEX ein wenig zu testen. Die Ergebnisse des Vergleichs mit REPLACEV, einer Funktion aus 1 UTILITY, mit verschieden langen Vektoren bzw. Teilvektoren waren überragend. Je länger die Zeichenkette, in der die Ersetzungen vorgenommen wurden, desto größer wurde der Unterschied zugunsten von REPLACEX.

REPLACEX funktionierte sogar noch, als REPLACEV mit WS FULL endgültig aufgeben musste. Dabei ist REPLACEV keine schlechte APL2-Variante für das Ersetzen der Vorkommen einer Zeichenkette durch eine beliebige andere.

Dies waren Versuche außerhalb jeglicher ernsthafter Anwendungen. Tatsächlich gehört das Ersetzen von Teilstrukturen durch Strukturen mit unterschiedlicher Dimension nicht zu den Stärken von APL, nicht nur in Sachen Performance. Das ist anders bei jeweils gleicher Größe. Der einfachste Fall, der im wirklichen Leben auch oft vorkommt, ist das Ersetzen von Dezimalpunkten durch Kommata und umgekehrt.

Da waren ja noch die "File Associations" als eine APL2 Post-Installationsaufgabe. Damit wird den drei APL2-Dateitypen APL, ATF und ANS eine Aktion und ein Icon zugewiesen. Doppelklicken auf eine Datei mit einem solchen Dateityp öffnet dann für diese den APL2 Library Manager (ALM). Von diesem erben die Dateitypen auch das Icon.

Diese Aufgabe konnte man bisher leicht mit dem Library Manager selbst erledigen: Mit einer der drei Möglichkeiten den ALM Manager starten und unter "Options" die "File Assiations ..." wählen und im folgenden Dialog die Zuordnungen vornehmen.

Nur leider funktioniert das mit dem Service Level 11 nicht so wie gehabt. Das hat nichts mit Vista zu tun und wird mit der kommenden CSD behoben sein. Die Zuordnungen können natürlich "von Hand" mit Windows Bordmitteln durchgeführt werden.

APL2 läuft unter Vista, dagegen ist prinzipiell nichts einzuwenden.

Es gibt mindestens noch eine kleine Ecke, die sich nicht ganz mit Vista verträgt. Trägt eine definierte Funktion, ein definierter Operator oder eine Variable ein APL-Zeichen im Namen, so wird der nicht immer korrekt in der Titelleiste des Objekt-Editors angezeigt.



Nicht immer heißt hier auch nicht immer: Für Computer, die ein wenig schwach auf der CPU- oder RAM-Brust sind, empfiehlt es sich den Ressourcenfresser Aero-Desktop abzuschalten. Als nützliche Nebenwirkung erhält man die Darstellung der APL-Zeichen in Namen als eben solche in der Titelleiste des Editors. Luxuswesen, die sich Aero leisten können, werden dagegen mit sinnlosen Objektnamen bestraft.

Man kann eben nicht alles haben. In dieser winzigen Ecke des uns bekannten Universums gilt gegenwärtig folgendes Gesetz: Entweder Aero oder APL. Solange, bis David neue Realitäten schafft.

Auch bei APL2 gibt es noch einige Dinge, die nach der Installation noch zu erledigen sind. Da ist als Erstes der mit Service Level 10 eingeführte "Configure APL2"-Dialog, der die APL2.ini produziert. Alternativ dazu gibt es immer noch die guten alten Umgebungsvariablen und APL2-Aufrufparameter, die per Windows-Batchdatei angelegt werden können.

Wurde unter XP die mit "Configure APL2" erstellte Ini-Datei noch direkt im APL2 bin-Verzeichnis abgelegt, ist dies unter Vista ein wenig anders. Das neue Sicherheitskonzept läßt grüßen! Statt dessen findet man die APL2.ini im "Virtual Store", genauer unter "\Benutzer\[Benutzername]\AppData\Local\VirtualStore\Program Files\ibmapl2w\bin", soweit bei der Installation die Standardvorgaben nicht überschrieben wurden.