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

[Elias Mårtenson]

First of all, I'm a newcomer to APL and even though I've hit 40 I feel somewhat like the new kid on the block. :-)

I haven't advocated plenty of new quad-commands or changes to the core language (although there are certainly a few of those that I'd like to see too, but I respect Jürgens wishes and vision for the project).

The native function interface was designed in order to be able to implement libraries that go beyond what the core APL language allows (file management is an obvious one, the SQL support being another, and the Emacs mode also needed to be able to communicate directly with the core interpreter through a back-channel which required yet another native library).

The benefit of the native libraries is that they are standalone and can be developed my anyone and they don't need to be delivered as part of the GNU APL distribution. My SQL library is a good example of this as it's completely separate (that said, if Jürgen is willing, I'm happy to see it included in the core).

All of the libraries that I suggested integration with would be implemented in a similar manner. It is no more an extension to GNU APL than libxml is an extension to C. It's just a library that happens to be implemented on top of a platform.

Like it or not, in order to be able to effectively use the tool (and even, dare I say it, attract some new user?) there needs to be an easy way to interact with the rest of the world. The world uses things like JSON, XML, spreadsheets and graphical monitors (notice the correlation with my list in the previous mail? :-) ).

Another community that I'm involved in is that of Common Lisp. This community have some similarities to APL in the sense that it's an old language (older than APL in fact) whose community is fairly small. In the last few years, Common Lisp has experienced a resurgence of sorts with new developers starting to use the language. It's nowhere near the size of the Ruby community for example, but it's large enough to be viable right now.

Arguably the biggest contributor to the resurgence of Common Lisp was the Quicklisp project which is a library manager that allows a developer to use a single command to download a library that provides some functionality, and it will be automatically installed along with any dependencies it may have. It can also update all libraries to the latest version using a single command. This project alone transformed what was an incredibly painful process requiring the developer to first identify what library he actually needed (there was no central repository) and then download it along with all dependencies and then attempting to get all of those running on his Common Lisp implementation of choice.

With Quicklisp, the process of installing, say, the XML library (called "cxml") was now reduced to typing (ql:quickload "cxml"). Just imagine the difference this makes to a newcomer.

This is what I would like to see for GNU APL. We obviously can't match Common Lisp in the breadth of libraries but we can at least make it easy to access the available functionality to "do stuff".

Ideally, I'd like to be able to type something similar to )COPY XXX where XXX is some library name, and everything would be loaded automatically (both APL code and the native code).

Regards,

Elias

On 23 April 2014 08:06, Peter Teeson <address@hidden> wrote:

David's is a thoughtful email which which we should consider without prejudice.
The ISO standard makes clear, in chapter 4, what it means to be compliant.

When I worked at IPSA Ken Iverson's office was just a couple away from mine.
He was very thoughtful of what should be added/extended to the language and the QUAD's.
At the time we were adding shared variables, fairly new at that time and long before APL2.

IPSA APL had a component file system, BSS, initially written by Larry Breed.
Because it was essential, it was integrated into IPSA APL and we had a set of Quad functions to use it.
I cannot recall now but I'm pretty sure they were not part of the APL/360 manual.

When we were exploring new capabilities we used to model them in APL first and there were
special privileges, really restricted to only some zoo members, to be able to run them.
Later on they might be written in Assembly, which was the implementation language used at that time.

Because I'm old now <and "old school" as well I guess> I suggest that we err on the side of caution.
Because the present GNU APL is the best thing that has come along in years, it would be a pity to
burden it with the sort of feature creep that has happened to far to many pieces of SW. Much ado about nothing.

Perhaps the place for the experimenting with these sort of things is in a branch, not the trunk.
And like fine wine let them ferment and mature in order to get the full flavour and benefit.
(Which reminds me time to pour a glass of red cab/sauv)

If I have misunderstood the gist of the various proposals then feel free to correct me.

respect…

Peter