Hi Blake,
I see what you are after.
You said earlier that you don't care how functions are stored
externally.
At the same time you want the internal representation to not
contain
additional spaces.
However, the internal representation is what is being stored on
)SAVE
or )DUMP. Therefore your requirement on the internal representation
prevents the functions to be store in a way that preserves the
indentation
inserted by the user.
First, I have never wanted to preserve the indentation provided by the user. In fact, I explicitly do not. APL is not an ALGOL-family language.
Second, there is, in this case, little relationship between the internal representation and the format of the save/dump files. You can store functions internally left justified and format them for a save/dump any way you like - just like the del editor.
In other words, if I would folllow your requirement on the internal
representation, then I have no choice than to follow suit in the
external
representation.
Not at all. You have C++ functions that write out the APL code. Those C++ functions can provide whatever format you like.
In yet other words, you want the "leading-space-less" representation
to be used everywhere: internally, in the ∇editor, in ⎕CR, and in
.apl
and .xml files.
That's not what I am saying. You store the functions internally left-justified. When you do [⎕] in the del editor, the del editor adds the desired formatting at that point. So, the user will see the comment and label lines indented differently as they should be when the user sees the function from the del editor.
IMHO the fact that the ∇-editor removes indentation is a nuisance
rather than a feature. You are used to it and want it back. The
GNU APL mechanism for solving this kind of differences in opinions
is preferences files and not fundamental changes of principles
of the implementation.
APL is what is defined by IBM and the standard. You can do whatever you like - but it won't be APL. I have several years working with IBM APL. I've also used several other APL's and, with very few exceptions, they follow the IBM standard. I have a keen eye and am merely trying to assist.
As a side note, what started all of this a few years ago is that the way you were handling function spaces actually broke code I had. My APL Editor uses ⎕CR to get at a function for editing purposes. I had used that editor professionally for years on IBM APL, TSR APL, APL 68000, Harris APL, and others. They all provided the function left-justified. Your ⎕CR did not.
I will be happy to make GNU APL behave as you prefer, but I refuse
to make it behave in a way that I do not prefer. Especially your
Rule #2 below is what I would hate to see. IMHO an editor should
change the text entered by a user as little as possible, even if the
old IBM APL2 editor did so.
My suggestions have nothing to do with my preferences. This is the way all APL's I've used work.
If you have a non-APL preference, it's your APL, support what you like. I am merely providing feedback on difference from the standard. It's up to you to follow that or support your personal preferences. Perhaps I can recommend this:
1. provide the standard out-of-the-box
2. add a preferences option to support your preference, and perhaps others, as an option
This way when people who know APL download and install GNU-APL, they'll see what they expect to see. When they dig into GNU APL they'll see the option and make a personal decision.
Thanks!
Blake
Best Regards,
Jürgen