Hi,
I really appreciate the discussions on this because I believe
there is a open issue (libraries and how to provision them).
1. First of all I would like to share my current point of view regarding
⎕-functions and
-variables. The (only ?) good thing about them is that they are ready to
be used from
the beginning of an APL session. Some ⎕-functions are definitely useful
while others
look more like vendor-lock-in features as David has correctly noticed.
But they have a
number of disadvantages as well:
- more effort (than native functions) to integrate them into GNU APL,
- shift of maintenance responsibility from the creator to core GNU APL,
- difficult to extend,
- they don't scale well (in terms of producing, testing and documenting
them).
- non-standard and therefore non-portability of code using them.
These were the main reasons for me to not implement them when asked to
do so, like
"why does ⎕xyz not work on GNU APL ?". Since GNU APL is public domain,
there is not
point in locking-in users.
2. The other traditional extension mechanism, shared variables, is a
little more modular
and avoid some of these disadvantages, but have others (awkward
interface, separate
thread or process needed, etc.)
As an intermediate summary, I will not put much effort into developing
new ⎕-functions
or shared variables. I may integrate shared variables contributed by GNU
APL users if they
are compatible with existing IBM shared variables.
3. This brings us to the point of libraries. Historically APL has always
been suffering from a
lack of libraries like we know them from other languages. There have
been APL code-snipplets
around, but using them has always been difficult. I would even argue
that the lack of a
mechanism to provide was one of the reason that APL has not been as
successful as other
languages. How else could you explain that eg. Perl is so much more
popular than APL?
That means that Elias is correct in asking for certain functions in
order to make GNU APL
more useful. And most of you seem to agree that such functions shall not
be part of
the core GNU APL, but in libraries. We already have a few libraries
created (FILE_IO,
emacs_mode, SQL databases, ... ) and I believe there will be more. What
I see technically
(and also considering my role in that) is this:
A. the extension mechanism used shall be native functions
B. A library consist of:
1. C/C++ support functions in the GNU APL interpreter (creating APL
values, access to values, etc.)
2. C/C++ code for native functions, typically wrappers to existing
libraries,
3. APL code (⎕FX of the native function, but possibly more),
4. documentation
Each of component 1-3 is optional, so you could have an APL-only lib or
a native-function-only lib.
I can take care of 1. because I expect that the number of such functions
needed will decrease
considerable over time.
For 2. it is possible to provision these functions as part of GNU APL
(as we have done it for
FILE_IO and emacs_mode) or outside GNU APL (as currently for SQL). There
are pros and
cons for both cases. I would leave it to the designer of a library to
decide whether she wants
to have it distributed with the GNU APL package or else to store on some
other repository.
In the first case we can then discuss the details.
For 3. and 4. I have no strong opinion yet. With the new )DUMP command I
have tried to
establish a basis for exchanging APL code in a generally usable (i.e.
UTF8) text format.
Such text files can easily be created, modified, and published on web
pages. The )COPY
command now accepts these files as input and can also be used
recursively. Pretty much
like #include in C/C++. I would prefer such text files over binary files
because of portability.
So the remaining question is where to store (eg. s...@gnu.org, github,
etc) and how to distribute
(contained in GNU APL tar file or separate) 2., 3. and 4. For me as a
designer that is not so relevant,
but I guess the the friends of GNU APL shall make themselves heard.
/// Jürgen
