[Bug-apl] My initial reading of Jürgen's libra ry proposal

[David B. Lamkins]

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.