Hi Blake
to conclude the discussion I made the following changes (
SVN 1259):
1.
⎕CR will always remove unnecessary leading and trailing
spaces.
Unfortunately this deprives the fans of indentation of any
possibility
to obtain their loved indented version back into APL. Therefore:
2. The unmodified (indented) version of a defined function can now
be
obtained with dyadic
37 ⎕CR instead of monadic
⎕CR.
3. Indentation can be controlled with preference
DISCARD-INDENTATION.
If set to
Yes then (hopefully) all indentation is
rigorously removed, and regardless
of whether the function is created via
)LOAD, the
∇-editor,
or
⎕FX.
Users should be warned that setting
DISCARD-INDENTATION might
also
(negatively) affect the content of multi-line strings in defined
functions and
maybe
⎕INP.
At this point I am not sure if all cases were properly caught, so
please test
this preference extensively and let me know if it fails.
Best Regards,
Jürgen
On 4/10/20 2:52 PM, Blake McBride
wrote:
Hi Jürgen,
Thanks for your response! See mine below.
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.
Yes, indeed. I just realized that with my last email.
Before that, I couldn't understand why you were saying what
you were saying.
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.
Agreed. I see the problem.
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.
Although that does fix ⎕CR, it still causes other
problems that initiated this whole second round of
discussions. In other words, I think your efforts to
support your preference is causing a rippling effect in
other areas - like the ⎕CR problem.
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.
Although I agree, it is "common behavior of several
implementations", it is also what long-time APL users
expect. When we don't see it, we start to question what
else is different. Additionally, as we've already seen,
those changes have unintended consequences.
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.
I deeply appreciate all that you have done. It is my
opinion that, in the long run, you will have played a very
major role in the survival of APL. I feel that a small
change here and a small change there over a long period of
time will morph APL into something else. That is one of the
reasons I don't want change.
Thanks!
Blake