[Top][All Lists]

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

Re: Loading .apl files differes from .xml workspaces

From: Dr . Jürgen Sauermann
Subject: Re: Loading .apl files differes from .xml workspaces
Date: Fri, 10 Apr 2020 14:31:15 +0200
User-agent: Mozilla/5.0 (X11; Linux i686; rv:60.0) Gecko/20100101 Thunderbird/60.6.1

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.
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.

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.



Best Regards,

reply via email to

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