I did bring up the topic of namespaces some time ago on this list, and Jürgen expressed some concerns with it.
My opinion is that they would be really useful. It is possible to handle a large number of libraries without namespaces (Emacs does not have namespaces either, and there are thousands of libraries for it) but it can be a pain, and you always have to prefix global symbols to ensure there are no collisions.
When it comes to packaging, the problems are much smaller than for, say, the Perl community. After all, the size of the GNU APL community is probably in the low-double digits. This is a benefit, as implementing a package system is much easier when there are a lower number of users (there is more room for experimentation).
My humble suggestion is as follows:
Provide a way of specifying one or more extension directories. One of these should be in the system directory (say, /usr/local/apl/extensions). There could be others, such as $HOME/.apl/extensions and perhaps something specified using an environment variable?). GNU APL would search these directories and each extension/library would be a subdirectory. The directory should contain all the required apl source files, as well as any native libraries. There also needs to be some kind of descriptor file that contains metadata such as author, documentation, etc. Now, one could even envision a way to have the C++ code be automatically compiled by the library loading machinery.
In any case, the idea here is that library can be contained in a single directory and that libraries shipped as part of GNU APL vs. ones delivered separately are the same, with the only exception being the directory they are located in.
Regards,
Elias
On 24 Apr 2014 03:39, "David B. Lamkins" <
address@hidden> wrote:
First of all, I want to thank everyone for carrying on this discussion.
Second, I'd like to echo the positive comments regarding GNU APL. I've
seen a lot of free APL systems come and go over the past 40 years; GNU
APL is really the first one that's both useful and open-sourced. My
heartfelt praise goes out to Jürgen and GNU APL's many contributors.
I'd like to shift the discussion slightly toward the notion of
programming-in-the-large. Libraries are a part of this, but there are
other considerations.
When APL was new, large software systems tended to be constructed using
a combination of purpose-built code and a limited selection of
special-purpose libraries. The libraries tended to be either designed
specifically for the larger system, or were carefully evaluated and
curated for inclusion based upon specific criteria.
The culture of library-oriented-programming, although discussed as a
desirable part of software engineering pretty much since the origin of
those discussions, has really only come to fruition in the past decade
or two.
IBM/ISO APL (i.e. the ancestor of GNU APL) was designed at a time when
libraries were scarce. As such, IBM/ISO APL is not well-suited to the
modern practice of mixing and matching from among a broad selection of
similar or competing libraries.
There are, I believe, two primary issues that ought to be addressed:
1. namespace management, and
2. package/dependency management.
Namespace management is simply a way of being able to use software
authored by various people or organizations without having to involve
the original authors in the resolution of conflicting identifiers. There
are nearly as many solutions to this problem as there are modern
computing languages.
Namespace Management (example)
------------------------------
In the APL world, Dyalog (which I cite only due to familiarity and
experience) has namespaces. You can download the manual from their web
site and get the full documentation, but I'll summarize to the best of
my recollection:
)ns <name> creates a namespace
)cs <name> sets the interpreter's default context to the given
namespace
Dyalog namespaces may be nested. There's a distinguished token to
identify the root namespace. IIRC, there's another distinguished token
to allow navigation upward (similar to .. in the Linux shell). You can
use dotted paths to name identifiers in other namespaces.
The name of a Dyalog namespace is independent of the identifiers created
within the namespace. This is an important distinction, as it allows the
application programmer to choose the name of the namespace.
I don't recall whether Dyalog has any quad-functions specific to their
namespace implementation. I imagine certain existing quad-functions and
system commands (quad-NC and )SINL, to name just a couple) would need to
be aware of namespaces.
To be clear: I don't have any particular affinity for Dyalog's
particular solution to the namespace problem. I do, however, believe
that *some* namespace solution is required in order for APL to be viable
for programming-in-the-large.
Package Management (discussion)
-------------------------------
I haven't actually seen a good example of package management in APL.
Dyalog has SALT (see the documentation on their web site); I believe
that SALT doesn't go far enough.
In my opinion, an APL package management system should address at least
the following concerns:
* provide access to repositories of code, both local and remote,
* maintain metadata to aid in the identification and selection of
packages
* allow access to multiple versions of each package,
* express and resolve dependencies among packages, and
* provide a command to instantiate a package and its dependencies
within the current workspace, automatically using namespaces to isolate
the packages from the application programmer's code.
I believe that such a package management system could be coded entirely
in GNU APL given the existence of a namespace facility in the core
language.
I have some preliminary thoughts regarding a design of an APL package
management system, but I'll save that discussion for later.
Anyhow, that's my musing for the day... I'll be interested to hear
whether anyone else thinks that it would be of value to push GNU APL
beyond a core plus libraries, toward some measure of support for
programming-in-the-large.