Re: [Bug-apl] Proposal wrt experimental code

[Juergen Sauermann]

Hi Peter,

sorry as well. I believe i was mislead by your earlier question for the
source of the Nabla editor.

I cannot give you a full answer because the question touches many aspects
of GNU APL, like how to do things, who does and maintain things, what do we like,
and so on.

But I can share some of my opinions with you.

1. How to handle code variants.

there are a number of ways to do it - branches in SVN,
options in .configure (→ "#ifdefs in C++), if statements, additional source files,
dynamic libs.

I am not at all a fan of branching. I managed to avoid it in my worklife - for good I believe -
when heading bigger software projects than this. There are many reasons - too many to
discuss it here. The others are OK and I would make them dependent on the particular example.

As long as the exprerimental code is not on a performance critical path, if statements are the easiest
to use and also the most readable. Otherwise #ifdefs via ./configure need to be used which is more
effort and less readable. A debug command to control this should be created.

Before putting these decisions into the source itself, it should be ruled out that the wanted behavior cannot be achieved
by dynamic loading which I see as a more modular approach. Sometimes only a point in the source is needed where you
can hook into. The way how Elias implemented the emacs mode is an example; it is rather tightly coupled to the core
APL but still completely optional and modular. There were a few hooks missing when Elias started and I added them as
needed.

2. And then there is a matter of style. My impression is that you have a similar view on it. If someone would tell me
"I would like to add an exprimental feature that allows a sequence of ASCII punctuation characters (or morse code) instead of
APL characters, then I would consider that as an attack on APL itself and fight it. Everybody is free to start with the GNU APL
code base and derive his own language from it (J, K, ... the alphabet is long). But I would not allow that back into GNU APL.
I have seen requests for "state-of-the-art" features that I would rather call "disgusting" even if they are useful. If I like BASIC,
for example, then I would just use BASIC and not try to make APL look like it. This probably sounds arrogant, but I take the
freedom to voice my opinion on this matter.

3. As a summary for the moment, if you think there is a useful feature for GNU APL, lets discuss it on bug-apl so that we get
an understanding how other people like it and then figure the best way to handle this in the source code. I am also working
on a web page with links to contributions related to GNU APL so that people do not need to scan the bug-apl mailing list.

/// Jürgen



On 04/30/2014 04:15 PM, Peter Teeson wrote:

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