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"
