Das waren die
guten Nachrichten über "IN". Kann ich also meine korrigierte Variante von "IN" durch die offizielle Version ersetzen? Das wäre erstrebenswert, geht aber nicht. Denn ich habe noch zwei weitere Dinge "verbessert" - verbessert im Sinne der Verwendung von "IN" in meinem APL-Workspace Crawler.
Das INen von großen geschachtelten Variablen kann sehr lange dauern und während dieser Zeit die kompletten CPU-Ressourcen in Anspruch nehmen. Dies kann nicht direkt IN oder )IN angelastet werden, denn der eigentliche Übeltäter ist ⎕TF.
Hierzu ein Beispiel: Auf meinem neuen 2 GHz Rechner dauert das Inen einer 10553x24-Matrix der Tiefe 2 ca. 20 Minuten. Die Größe der Variable ist, gemessen mit "4 ⎕AT", 9.117.824 bzw. 1.744.766. Die Größe der ATF-Datei, die ausschließlich die Variablen enthält ist, ca. 2MB.
Für den meinen Crawler, der sowieso nur nach Funktionen und Operatoren sucht, war das pure Zeit- und Ressourcenverschwendung. Ich habe mir daher die Definition von IN vorgenommen und entsprechend geändert: Hast du gerade eine Variable zur Bearbeitung vor dir, dann gehe zum nächsten Objekt. Einfach und effizient!
Wäre das nicht auch ein Feature für die offizielle Version von "IN". Auch dem APL2 Library Manager würde es gut zu Gesicht stehen: Der Anwender wird vor dem Einlesen komplexer APL2-Variablen aus ATF-Dateien erst mal gefragt, ob er sie wirklich sehen will - oder ähnlich.
Die zweite Verbesserung betrifft generierte Zeitstempel von Operationen aus ATF-Dateien, die keine Zeitstempel vorsehen, oder die total ruinierte Zeitstempel enthalten. Beides kommt auf meiner HD vor, ersteres bei alten ATF- bzw. AIO-Dateien.
Sowohl "IN" als auch )IN generieren für Operationen aus solchen ATFs als Zeitstempel den Zeitpunkt des "Fixens" der Operation. Aus alt mach neu! Das gibt natürlich ein vollkommen schiefes Bild über das Alter der Operationen in diversen ATF-Dateien.
Stattdessen verwende ich die "Last Modified"-Zeit der ATF-Datei als Ersatz für fehlende Zeitstempel. Dieser Zeitpunkt ist sicherlich näher an tatsächlichen Zeit des letztmaligen Fixens der betroffenen Operationen als der Zeitpunkt des Einlesens. Ich finde, auch diese Änderung wäre für "IN" und auch ")IN" eine Verbesserung.
Da ich gerade über "IN" meckere ... Das explizite Ergebnis von "IN" ist Schrott: 1, falls alles funktioniert hat, 0 sonst. Die neue externe Funktion "COPY" ist da schon eloquenter:
result - a seven items array: [1] return code ... [2] reason code ...
(s. User's Guide, S.208). Ein return code von 0 bedeutet wie üblich: Success! Damit kann man was anfangen und aussagekräftige Fehlermeldungen generieren.
Warum nicht so mit "IN"?
ap127