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
