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
