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
