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

[Blake McBride]

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 <address@hidden> 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.