Hi Blake,
I believe your 1, 2, 3 below is exactly the current priorities of GNU
APL and 3. is already
present.
We use shared libraries for extending APL so you don't need an extra
developer lib
for that. The only thing needed is a header file declaring the functions
available in
GNU APL (maybe not all of them), compile, and then dlopen() the lib in
APL (which
is already the essence of GNU APL native functions).
I would not make such functions ⎕-functions, (see my previous posting)
because
that would blur the line between user-defined and system functions.
/// Jürgen
On 04/23/2014 02:10 AM, Blake McBride wrote:
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
