|
| From: | Blake McBride |
| Subject: | Re: Loading .apl files differes from .xml workspaces |
| Date: | Sat, 11 Apr 2020 19:09:48 -0500 |
Hi Blake,
i am getting this:
* )clear**
**CLEAR WS**
** ∇abc**
**[1] 1**
**[2] 2**
**[3] 3**
**[4] [⎕]**
** ∇**
**[0] abc**
**[1] 1**
**[2] 2**
**[3] 3**
** ∇**
**[4] ∇*
I suppose that either your preferences file is wrong (e.g. wrong profile),
or not read: (check with apl -l 37),
or your recompile has not caught all dependencies.
Best Regards,
Jürgen
On 4/10/20 6:45 PM, Blake McBride wrote:
> 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 <mailto:mail@j%C3%BCrgen-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 <mailto:mail@j%C3%BCrgen-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
>>> <mailto:mail@j%C3%BCrgen-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
>>
>>
>
| [Prev in Thread] | Current Thread | [Next in Thread] |