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

[Juergen Sauermann]

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