Re: Loading .apl files differes from .xml workspaces

[Dr . Jürgen Sauermann]

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