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" <dlamk...@gmail.com> 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. > > >
