Re: [Bug-apl] Proposal wrt experimental code

[Peter Teeson]

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