Thank you Jürgen for the clarification. You make a great argument, and I personally have no problem accepting that.
Also, as you say, the community is so small that names shouldn't really clash. I suppose if the unthinkable happens and the community size were to grow to 4 digits, this the entire issue could be revisited. To shift this discussion from namespace to (what I previously mentioned being more important) that of library packaging: I don't think using Linux packaging is the best idea. I run Ubuntu and OSX at home, and Arch Linux and Red Hat at the office. That's four different packaging systems right there. Rather, I'd like to see something like Quicklisp for Common Lisp, Gem for Ruby or Pip for Python. All we have to do is to define a simple description format, and a central repository. I think I could implement such a thing pretty quickly as a proof of concept if this is something that would be acceptable. Regards, Elias On 25 April 2014 01:51, Juergen Sauermann <juergen.sauerm...@t-online.de>wrote: > Hi David, > > thank you very much for all the flowers from you and the others in the > last days. > Not my birthday yet, but I'll keep them until then. > > I agree that dependency tracking could be a good thing. Maybe we can use > the dependency > system of RPM or Debian packages for that (GNU APL has make targets for > RMPs and Debian > packages already. Other proposals are equally welcome, of course. > > My opinion regarding namespaces is not so positive and I would like to > explain why. > > 1. Having seen names[aces in C++ for a couple of years now I would rate > them somewhere > between superfluous and annoying. > > 1a. One of the arguments for namespaces was name clashes in different > libraries. However IMHO > namespaces merely shift the problem to another level because you can now > have clashes between > namespace names if two libs use the same namespace. It is only a smaller > probability. > > 1b. In the old days we would write cout << "Hello". Now we say std::out << > "Hello". But since > nobody really wants that, we then say "using namespace std;" which brings > us back to where > we started. > > 1c. I know that namespaces can solve certain problems, but I cannot > remember to ever have them. > > 1d. I don't like it at all if a language has redundant features. In C++ > classes and structs are already > namespaces of their own. So why replication a subset of that functionality > and call it namespace? > > To summarize, on my personal bottom line, the saldo of C++ namespaces is > slightly negative. > > 2. Now to APL where I believe namespaces are even worse. In addition to > the above we have: > > 2a. namespaces in APL are not standardized. If we would use them for > libraries then these libraries > could not be used with other interpreters that do not support namespaces. > I believe we should instead > do the opposite and create libraries that can be used on all interpreters. > > 2b. Using a dot to separate name components is a truly bad choice because > it interferes with the inner > product. For me as a C++ programmer a double colon would have been much > more appropriate. If we > would go for ::, however, we would divide the APL world even further into > no-namespacers, dot-namespacers, > and double-colon-namespacers. > > 2c. A good naming convention - in the old days we used ∆ for that - would > give us almost the same benefits > without any incompatibility. For me it is not obvious why e.g. sql.foo > should be any better than sql∆foo. > > 2d. I believe the APL community is so small that name clashes are not > really an issue. > > 2e. For native function based libs there is no need for namespaces since > the name used in APL is > completely separated from the symbols used on the C/C++ side. That is the > C/C++ codes of different > libs being used cannot clash. > > > Best Regards, > Jürgen Sauermann > > > > > On 04/23/2014 09:31 PM, David B. Lamkins 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. >> >> >> >> > >
