Hi Jürgen:
So sorry but we are not understanding each other on this.
I apologize for my inability to state it more clearly.
This is a long reply but I'm trying to explain it with words.
Too bad we can't sit down over a mug of beer (or a cup of tea) and discuss it
IRL.
My proposal is NOT specific to the ∇-editor command [A⎕B] .
I am NOT talking about making [A⎕B] configurable. That would be an abomination.
It is just a small "bug" which will be repaired. It has nothing to do with my
proposal.
I'm trying to look at a much bigger picture.
The core implementation of GNU APL is the ISO 13751 plus some IBM APL2. It is a
thing of beauty.
What I was trying to do was outline a generic way to allow the development and
eventual release of
"add ons" in a way that keeps the core implementation "pure".
We all know of products on the market that have "feature creep" which need to
be maintained forever
because some users have come to rely on them. That's OK if the other users
don't have to include them.
So my proposal is for a generic mechanism that allows experimentation (and
eventual inclusion in the distribution) but can be excluded (or included) as a
default - it requires a user to take action to include or exclude it.
The only method I could think of was the one I proposed. Probably there is a
better way.
Let me take a specific example:
(0) We make the design decision that the core code should include an
implementation
of the IBM APL2 Editor 1 a.k.a. the Line Editor.
This has already been done but may need some tweaking.
(1) We also want to experiment by adding the IBM APL2 )EDITOR command. This is
an "add on" because
the standard clearly states it's implementation defined. (See my earlier
verbatim quote from the standard).
What are the steps?
(a) Implement it first locally on the developer's installation. Test it and fix
bugs.
(b) Make it available as part of the code distribution for wider testing - but
as experimental code.
(c ) When it's stable, release it as optional code - (i.e. no longer
experimental and subject to withdrawal).
The default might be to include it (the user does nothing) or it might be
to exclude it (the user has to
explicitly include it)
Now suppose we want to allow )EDITOR II or )EDITOR VI or )EDITOR Emacs.
We need to write supporting code to interface (steps a, b, c, above).
It should NOT be part of the core implementation - it should be an "add on".
It's up to the end user to include or exclude it.
Similarly we can imagine a better way to implement ⍳ and we want to compare the
performance of the old one with the new one. We can use the same mechanism to
experiment and perhaps eventually release.
But we are not irrevocably bound to the code because it's experimental. (At
IPSA we defined ⍵ as the primitive to use for experimental implementations of
primitive functions and operators. We had both the existing and the new version
available in the interpreter. That way we could test both of them at the same
time.)
We would still follow the a,b,c, steps above. Of course in this case if the new
implementation was significantly better it would be included by default. (Of
course in a production time-shared system you could not have both
implementations at the same time.)
Don't know if this explains it better but anyway thanks for reading it.
respect…..
Peter
