Hi Blake,
see below.
Jürgen
On 4/10/20 1:34 PM, Blake McBride
wrote:
Hi Jürgen,
Please see my response in-line below.
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.
This is the core of the disagreement between you and me.
You don't and I do.
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.
Yes, I have C++ functions that write out the APL code. But the
argument of the
function that writes an APL function in .apl or .xml format is the
internal representation.
There is no other representation once ⎕FX or the ∇-editor have done
their work.
If we discard additional spaces in the internal representation then
they gone
forever and there is no way to get them back.
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.
Its not what you are saying but it is the immediate consequences of
it,
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.
And I appreciate that.
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.
As I said earlier, I will fix ⎕CR to not show leading spaces and
independently of the
user's preference file. That does not, however, imply a change of
the internal
representation. The internal representation plays a role in more
places than those
that the APL user sees and therefore fixing ⎕CR is far simpler than
changing the
internal implementation.
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
Neither the APL standard (ISO) nor IBM's APL2 Language reference is
specific concerning
leading spaces in tge ∇-editor. IBM itself has taken quite some
freedom to implement the
∇-editor differently on its different platforms. Therefore the
"standard" that you refer to
seems to be a common behaviour of several implementations.
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.
I will do something along those lines. However, to prevent existing
GNU APL users from
surprises (i.e. for the sake of backward compatibility), I will make
the current behaviour
the default.
Thanks!
Blake
Best Regards,
Jürgen
|