Re: [Bug-apl] Proposal wrt experimental code

[Juergen Sauermann]

Hi Peter,

there is very little emacs related code in the GNU APL core. The --emacs command line option
replaces the  escape sequences normally used for colors by sequences that are easier to detect
by emacs so that emacs (which intercepts the GNU APL output) knows if a line printed by the
interpreter is (echo of) input, output or error information.

The other thing is a handful of hooks (callback functions) that are called when somebody sets them.
The GNU APL core has no idea what these functions may do and it does not care either. The hooks
can also be used by other editors or other functions.

I have a mental model of what the critical path in GNU APL is. The inplementation of the various primitive
functions, the creation and destruction of APL values, and the interpretation of Token in function bodies
belong to the critical path, which means that they have direct impact on the performance. On the other hand,
commands, editors, output formatting, workspace loading etc. are not on the critical path because they directly
or indirectly relate to human interaction and we humans are no so fast.

Now if somebody asks for a change then my internal algorithm is roughly this:

1. Is it improving GNU APL? Reject if not.
2. can it be achieved with existing means? Probably reject if yes.
3. is it on the critical path?
   yes: think twice (at least). If still yes make it ./configurable. I that is impossible: reject
   no:  think of hooks that are also useful for similar cases

I have been thinking about modularization a few more things in GNU APL. One is editors and the other is primitive functions.

When you look at Nabla.,cc then you will have seen that it is a rather crude implementation. I was busy with other components
of GNU APL at that time and just wrote it down without too much thinking. So it basically contains what was needed at that
time to defined functions in scripts. I am normally running GNU APL from a script and not interactively, so I use vi or
xterm cut-and-paste rather than ∇ to define APL functions.

modularization of primitive functions can be very easily achieved. Every primitive functions has its own class, derived from Function with
a single instance called 'fun' . So there are many such 'fun' objects in GNU APL, but each belongs to a different class. When a Token
representing a primitive function is created then a Function * is created as &fun. Now, instead of thating &fun directly, we could initialize
a Function * beforehand and copy it when a token is created. This would have no performance penalty at all, and users could change the
pointers There are numerous uses of this: alternative implemnation of a function,  statistics of function calls and arguments, benchmarking
to name a few.

In summary, when I make non-trivial changes in GNU APL then I normally think about how to make that in a way that is
modular and useful for other purposes as well. I haven't reached that everywhere yet, but that should be the direction.
I am not too concerned about too many requests because my response (if accepted in above algorithm) to provide missing
hooks to enable rather than to implement them.

Best Regards,
/// Jürgen


On 04/30/2014 10:21 PM, Peter Teeson wrote:

Hi Jürgen:

(1) I completely agree with you about branching. My working world experience was similar ;}

As to who decides what's in the core code - I take the position that as the designer and implementer it is entirely your decision.

IMHO you are the Linus of GNU APL. What you have done and how you write code is most elegant.

(2) Absolutely agree 100%! My fear is the stream of requests for "feature x" or "why can't GNU APL do what Dyalog does" etc. We've seen a few recently. No objection if people want to do it. But if added to the core code it could quickly become pretty ugly. Instead we need a defined mechanism to allow "add ons". Certainly dynamic loading is part of the answer ut not the whole answer.

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.

Yes this is what started my thinking on this issue after Elias urged me to use Emacs and I found the "special case" code in the core APL to enable things for him. I got a bit concerned about it. 

Completely modular - is there an option of some sort of option to not include the src/emacs code in the build? I only found the command line startup option --emacs. 

respect….

Peter