Greetings, Your email sparked many thoughts. Not that my opinion necessarily counts for anything, I think this should be GNU APL's priority list:
1. Fix all known bugs and portability issues as they are discovered. 2. Support all of APL's standard defined features (i.e. trace, stop, etc.) 3. Create a generic mechanism whereby APL can be arbitrarily extended without re-compiling its source. This means creating a quad function to load, execute, and interface with shared libraries (so/dll/etc). It also means standard ways of communicating data back and forth. Doing it this way, all extensions can/should be done via shared libraries and APL glue code. This way modules (shared libraries & APL glue code) can be added for component or keyed file systems, GUI libraries, Regex, XML, etc.. The APL source would have to be enhanced a bunch of times to increase the generality of its interface to the external object. This would occur as limitations or inconsistencies are discovered. After a time, this interface will stabilize. I know GNU APL already has this, I just think it needs to mature - and it will as we hit the interface with a greater variety of needs. Just thinking out loud for a moment, perhaps a GNU APL developer library can be built that the shared objects can utilize. It would provide functions to translate APL objects to and from C/C++ objects and other functionality that would make it easier to write the extension modules. You state: "The obvious question is: Why would we want another open-source APL?" Another? There are only two other open-source APL system worth even mentioning: NARS2000 & OpenAPL. NARS2000, while good, suffers from two problems. First it is (unfortunately and unnecessarily) bound to Windows. The second problem is that it has insufficient persistence capabilities - only the rawest. Already GNU APL puts it to shame. OpenAPL is an old hack that was whipped together in a short time and never really worked. IMO, GNU APL is a thing of beauty. It's available in source, it's close to complete, it's portable, it is well supported by the author and the community. And, with all the off-putting, insulting communities out there, the GNU APL community is fantastic! I have waited 30 years for something like this, and I like and appreciate it! So, I think there is nothing like GNU APL. It is a gift. As the generic interface is enhanced, and more modules are built, this could become extremely powerful. In fact, I think GNU APL can surpass the APL vendors easily. Given source access opens up the system to many, many developers. Just think about Linux. The stability and efficiency of Linux far surpasses that of Windows and even Mac OS/X. With respect to the compiler bit, APL has always stressed the use of array processing rather than loops. APL is at a good place with respect to the increase of multi-processors. The value of a compiler decreases as one increasingly does thing in an APL/array oriented way. The interpreter orientation of most APL's enables much or APL's development conveniences, appeal, and productivity. I think an APL compiler is the subject of a different project. Just some thoughts. Thanks. Blake On Tue, Apr 22, 2014 at 4:10 PM, David B. Lamkins <dlamk...@gmail.com>wrote: > Just for the sake of discussion, and not because I specifically object > to any of the proposed library bindings: It'd be nice to see some > motivation for mapping new libraries into/onto APL. > > I know that Dyalog APL has all of the features proposed by Elias (and > more). I don't, however, assign much weight to the "keeping up with the > Jones'" argument. There's already a solution (Dyalog) for programmers > who need some combination of those features. (Granted, Dyalog is not > free. On the other hand, they've invested many hundreds of person years > of programmer effort into their product.) > > As a long-time student of APL, I try to be sensitive to the thinking > that served as the foundation of the APL design. The history of APL > tells us that the designers tried to be careful about considering how > new features would fit into the language. > > With the commercialization of APL, IBM's competitors strove to > differentiate themselves by introducing new features which were mutually > incompatible, leading to vendor lock-in and fragmentation of the > market. > > Given that GNU APL hews to an established standard, there's a chance for > other development teams to introduce comparable products. Having a > common language (something that the surviving commercial APL vendors > don't have) is, I think, a competitive benefit. > > The obvious question is: Why would we want another open-source APL? > > GNU APL is (modulo the occasional bug) a capable and nearly-complete > implementation of IBM/ISO APL. That's good news. > > On the other hand GNU APL is (by design) an interpreted language, with > all that implies. There's going to be an upper-bound on performance > based upon not having a compiler that can take full advantage of the > underlying hardware. While this might not be an issue for many people, > it's not difficult to imagine applications for which a significant > performance boost would be an advantage. > > I can certainly envision that someone may want to branch and rework (or > completely reimplement) GNU APL as a compiler. > > To the extent that the current GNU APL community introduces extensions > to the language the work of subsequent maintainers is made that much > more difficult, particularly in the case where the details of an > extension have a temporal nature (i.e. things that are the way they are > due to convention rather than underlying principles). > > I'd argue that everything on Elias's list is guided by convention. Data, > document and graphics formats come and go. (APL has been around for 50 > years. How many graphics, data interchange and document formats have > come and gone in that period?) Even something as pervasive as regex > needs to be qualified by the question: "which regex?". To my way of > thinking (more on this in the summary) this argues against building > dependencies into the core language for the sake of these features. In > other words: by all means let's build some useful libraries that can be > bound by the existing quad-FX mechanism. But let's think long and hard > before we let support for any of these new libraries require specific > new APIs or datatypes in the core of GNU APL. > > Again, I don't mean to shoot down your wish list, Elias. I would, > however, like to initiate a dialog regarding the best way to address > your concerns without introducing "accidental complexity" into the core > of the GNU APL language. > > For example, let's talk about graphics. > > One of the first questions that comes to mind is this: Even if all you > do is read and write image files, how do you deal with the image data > type in APL? Do you introduce the notion of a blob? Does the blob have > associated metadata? How does the interpreter need to change to deal > with blobs? Alternatively, let's say that we invent a mapping from > images to APL data and back to images. APL, particularly as an > interpreted language, would probably not be most programmers' first > choice as a tool to create or manipulate images. What's the use case > driving APL as an intermediary rather than some other tools designed > specifically to work with images? > > I'll stop here because I'm laboring under a lot of assumptions, many of > which may be wrong. Perhaps I'm missing the point entirely. > > On the other hand, I have an admitted prejudice against design by > accretion. I believe that a software system design is best served by > careful consideration of how all of the parts interact. It's fairly easy > to add features to software; it's exceedingly difficult to keep software > from suffering bit-rot as a result of feature accumulation. > > Again, I think it would help us all to have some concrete examples of > applications that would best be served by any new features / libraries / > extensions. > > > On Tue, 2014-04-22 at 22:33 +0800, Elias Mårtenson wrote: > > Oh, and a few other libraries I feel would be useful to have wrappers > > around include: > > * Regex: > http://www.gnu.org/software/libc/manual/html_node/Regular-Expressions.html > > * JSON > > * XML > > * Images loading and saving (libpng for example, or even easier: > > netpbm) > > * Ability to directly load spreadsheet files? (LibreOffice and > > Excel). I suppose one could easily go through CSV though. > > There are plenty of others, but those are the ones I have missed. > > Especially Regex would be incredibly helpful when reading texual input > > and you want to get it into some kind of array-based format for APL > > processing. > > > >
