Re: [Bug-apl] My initial reading of Jürgen's library proposal

[Juergen Sauermann]

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.
>