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
