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.