First, my thanks to Jürgen for all the time and effort that went into this proposal.
I found some of the specification regarding components to be mildly confusing. I'm particularly confused by the nature of C3. Also, there's this matter: A source file's first two characters are #! or ⍝! depending upon the component type. This raises the question of whether GNU APL will be (or has been) changed to accept ⍝! rather than #! as the first two characters of a .apl file. I'd like to point out some possible limitations of the proposed approach. I may have, on my first reading, missed something that would have addressed these concerns. If so, I apologize for the oversight. 1. I don't think that the encoding section goes far enough. As you know, there are cases in which different code points may be used for comparable APL characters. It reasonable to suggest that different APL interpreters should be accepting of such variations. The alternative would be to fully define the encoding to be accepted by compatible interpreters; this'll be an uphill struggle in the long run. I see this one problem (assuming that an .apl file will no longer require a #! header) as the biggest challenge toward making the library proposal usable outside of the GNU APL community. Conversely, this is one of the strongest arguments in favor of using an interpreter-specific library loader instead of )LOAD. 2. The proposed set of library names (workspaces, wslib1..wslib9) and their corresponding denotation at the interpreter's command level (0..9) is an IBM-ism and not part of the ISO standard. Interpreter vendors may choose other approaches; both for naming library paths and for referencing them in the )LOAD command. In short, the use of )LOAD as an implicit part of the packaging mechanism may limit the audience of this specification. 3. There's an implicit assumption that a .apl file is simply a script to be read by the interpreter. This begs the question of how other interpreters might limit the contents of a .apl file or the manner in which it is to be loaded by the interpreter. For example, an interpreter might treat an .apl file as APL code and prohibit or ignore the use of system commands. Another possibility is that an interpreter may only support the loading of a .apl file by passing its name to the interpreter from the shell command line. 4. I find myself confused by the reservation of multiple library locations for the same library level (L1, L2, L3). Does this mean that a particular library must be bound by convention to a specific directory? I'm wondering in particular about how )LOADing of dependent libraries could otherwise work unless a package is forever bound to a particular library. 5. The in-tree/out-of-tree distinction for native code (e.g. .so and .dll files) makes me uncomfortable as regards applicability of this specification to interpreters other than GNU APL. 6. It's unclear to me how a single library might be decomposed into multiple source files (other than the specified .apl and .txt files). 7. There's no provision to associate version numbers with libraries or to load a specific version of a library. This could be problematic in terms of being able to load independently-developed systems that depend upon a shared library having a version-specific API or semantics.
