[Bug-apl] A call for justification of feature / library / extension proposals (was Re: Tk/Tcl interface)

[David B. Lamkins]

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.