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