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.