[Bug-apl] Proposal wrt experimental code

[Peter Teeson]

Hi Jürgen:

This is a proposal for a mechanism to allow experimental code but still 
distribute it without becoming part of the "officially supported" code base. My 
reasons for proposing this have been stated previously but to recap:

"Experimental code too often becomes the de facto released code and is almost 
impossible to withdraw once users have become "addicted" to it. Like fine wine, 
design and implementation requires a maturation period. 
As developers we need to freely experiment. But we should be able to withdraw 
or replace such code when needed without negative consequences."

This proposal relates to distribution code; probably what's not in the trunk 
doesn't need it:

(0) In configure.ac. (I don't know the AC_… mechanisms) add something to 
indicate an XPERI capability. Default set to off. Run autoconf to generate a 
new configure file.

(1) Allow the end user to do ./configure --onXPERI (again I don't know the 
language) for those users
who want to experiment.

(2) The user does make ; sudo make install.  On launch the user would do apl 
--onXPERI <number> where
each number refers to a specific experiment. <number>  might be in a range from 
1 - 10 e.g. if we don't want to have to much experimental code at once.

For example if I wanted to experiment with implementing the )EDITOR command I 
might be assigned the number 8.

(3) I would have to add to Command.def, Command.hh, and Command.cc. But unless 
I had specifically
turned on experimentation and for the )EDITOR command I would receive BAD 
COMMAND. 

(Note: If the addition to Command.def could be made dependant on --onXPERI  8 
then that would be automatic. If not then the actual cmd_EDITOR code would have 
to print the BAD COMMAND message)

Clearly this is only talking about commands but something similar could also be 
done for APL primitives.
At IPSA we used ⍵ and it only ran from an )OPR terminal in the fishbowl (where 
the operators were - highly restricted of course). But we were a time sharing 
operation and could not afford to let just anyone experiment.

GNU APL is primarily, but not necessarily,  a single user product. But in 
principal this idea could also work when we want to compare different versions 
of a primitive to see how well the new "optimized" one performs.

Any way it's just a suggestion. Comments solicited.

respect…..

Peter