Re: [Bug-apl] Proposal wrt experimental code

[Juergen Sauermann]

Hi Peter,

there are already a number of facilities in GNU APL that can be switched
on and off via ./configure, for example Assert(). See the macros in 
configure.ac
that end in _WANTED to see how thjis works.

I guess what you are after is ∇-editor command [A⎕B] . I would rate the 
lack of it
as a bug (even though the ISO standard does not mention it) and that 
should be
fixed rather than being able to turn it on via configure. configure MAY 
be necessary if
you use non-standard libraries, but I hope this will not be  the case 
for A⎕B.

There would be some disadvantages in making A⎕B configurable with 
default off.
One is that many users will not turn it on, so errors in it would not be 
detected immediately.
The other is testing: we would have to produce 2 different versions to test.

In summary, we should keep it simple and implement [A⎕B] directly.

Thanks,
Jürgen



On 04/29/2014 06:28 PM, Peter Teeson wrote:
> 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