Thanks!
I have: DISCARD-INDENTATION Yes
in my ~/.gnu-apl/preferences file, however:
∇abc
[1] 1
[2] 2
[3] 3
[4] [⎕]
∇
[0] abc
[1] 1
[2] 2
[3] 3
∇
[4] ∇
∇abc[⎕]∇
∇
[0] abc
[1] 1
[2] 2
[3] 3
∇
As you can see, the indents are still there.
Thanks.
Blake
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,
> Jürgen
>
>
>
> 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.
>>
>> Jürgen
>>
>> 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
>>> 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
>
>
>
>
