hi David,
thank you very much for your feedback. See some answers inline below...
/// Jürgen
On 05/10/2014 08:40 PM, David B. Lamkins wrote:
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.
The idea behind C3 is simply that it works for GNU APL but cannot be
ported easily to other interpreters
because it uses GNU APL specific features (most likely native functions).
One of these GNU APL specific features is # as start of comment and, as
a consequence, #! at
the start of the file (which then is understood by execve() in GNU/linux
and probably POSIX).
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.
When you )DUMP a workspace in GNU APL then it produces a file that
starts with #! so that you can run it as
APL script without changing it. This is fine for C3 because they can use
GNU APL specific features.
For C2/C1 this is not OK since #! may not be understood by other
interpreters. Therefore I proposed a valid
APL comment ⍝! instead.
I have changed GNU APL lately to understand both in )LOAD and )COPY.
Note that the #! vs. ⍝! was not meant to identify L1, L2, or L3
libraries but merely to minimize the effort of the
library writer on one hand and compatibility of L1/L2 on the other.
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.
Agreed. I was trying to write down the ideas that I found important
first and encoding was
not one of them because GNU APL is rather tolerant as far as different
encodings are concerned.
Please feel free to submit some text for this.
I believe that the success of APL libraries will be influenced by their
ease of use. An interpreter
specific loader is a possible solution but if we can avoid it then we
should try to. I would argue
that encoding differences alone should not justify it.
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.
Yes. an IBM-ism, but adapted by GNU APL. The point was actually the
library numbers which
are also used by other interpreter i guess. The directory names
(workspaces, wslib1-9 are
used in the GNU APL package) for libraries shipped with GNU APL. The
user can configure her
own names in the preferences file.
What I was after is not so much the library directory names, but to not
mix different library types
in the same directory. I have changed SHALL to SHOULD, making it a
recommendation rather than
a requirement.
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.
Thats is the idea. We could actually restrict the use of commands in
library to anything other
that )COPY. Another interpreter could then easily emulate the APL lines
with ⍎ except for function
definitions.
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.
As above, it SHOULD. I am a bit afraid of a situation where loading of
libraries fails only
because they are stored in the wrong location or because of a wrong
library reference number.
If we provide some rules for that then we might avoid such failures. An
easy way out would be
to store everything in one directory, but I am not sure if that is a
good solution.
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.
Yes. I guess we should split the document into a GNU APL specific part
and a general part,
Right now it may be simpler to have it in one document to simplify the
discussion, but then
it should be split. I am note sure where all this will lead us, but we
could post it on comp.lang.apl
if we believe it is worth it.
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).
In GNU APL you would do it like this:
)COPY src1
)COPY src2
...
where src1 etc. could do their own )COPY. This is, of course, recursive
(like #include files in C/C++).
In other interpreters you would basically the same, but the sub-)COPY
would be done
when the library is built so that the user would do a single, flat )COPY.
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.
This is supposed to be handled by the meta functions in the library.
These functions provide
sufficient information about versions, requirements, etc. The naming
conventions for the meta
functions make it easy to )COPY them out of a library without muddying
the own workspace.
