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.
