[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Loading .apl files differes from .xml workspaces

From: Blake McBride
Subject: Re: Loading .apl files differes from .xml workspaces
Date: Fri, 10 Apr 2020 11:45:42 -0500


in my ~/.gnu-apl/preferences file, however:

[1] 1
[2]      2
[3]          3
[4] [⎕]
[0]   abc
[1]   1
[2]        2
[3]            3
[4] ∇
[0]   abc
[1]   1
[2]        2
[3]            3

As you can see, the indents are still there.



On Fri, Apr 10, 2020 at 11:13 AM Dr. Jürgen Sauermann <mail@jürgen-sauermann.de> wrote:
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,

On 4/10/20 2:52 PM, Blake McBride wrote:
Hi Jürgen,

Thanks for your response!  See mine below.

On Fri, Apr 10, 2020 at 7:31 AM Dr. Jürgen Sauermann <mail@jürgen-sauermann.de> wrote:
Hi Blake,

see below.


On 4/10/20 1:34 PM, Blake McBride wrote:
Hi Jürgen,

Please see my response in-line below.

On Fri, Apr 10, 2020 at 5:07 AM Dr. Jürgen Sauermann <mail@jürgen-sauermann.de> wrote:
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

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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]