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

[Peter Teeson]

This discussion is and has been healthy and useful - at least to me.
Jürgen's point's wrt the open issue of libraries etc gives us good ground to 
stand on.
Are we not all "newbies" wrt GNU APL even those who have a history using APL? I 
certainly feel that way.

Personally there has been an underlying philosophy one tries to follow in 
computer programming.
How best to resolve the tension between immediacy and elegance; between 
commercial deadlines and beauty.

And the issue of libraries and other add ons is part of a larger one - which 
language to use for implementation.
Because the choice of language so often conditions and constrains the solution 
set of the problem.
Personally I cannot recall how many times I have wished for access to call into 
APL to use it's array processing strengths.

Each language has strengths and weakness': Assembly,C/C++/Obj-C, Lisp. SNOBOL, 
COBOL, Fortran, APL, ADA, PL1, OpenGL, etc, etc.
To me these are all merely tools that should be available to artisan 
programmers to use wherever and whenever appropriate.

So in an ideal world one would be multi-lingual and be able to make use of 
whatever "tool" one chooses at the moment.
Providing GNU APL with an elegant and beautiful mechanism for libraries is a 
highly worthy objective.

Totally agree with Jürgen's quotes below. 
But in this exploration stage perhaps we should branch this off, or use some 
mechanism to indicate it's experimental.
This so that it can be withdrawn or deprecated should it turn out not to be the 
"best" solution.

from Jürgen's email:
"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. 
...
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"