Re: Loading .apl files differes from .xml workspaces

[Dr . Jürgen Sauermann]

  
  
Hi Blake,

On 4/8/20 9:17 PM, Blake McBride wrote:


  
  
Hi,


As far as I am aware, the del editor displays functions as
  you do - including the indenting of labels and comments.  Yes,
  it helps looking at code.  I am certainly not suggesting
  changes to that!  The point is that the del editor can add
  that formatting when displaying a function.  That format
  should not be retained internally.  Keeping that format
  internally is causing all of these problems.


  

Actually no. On my APL2 (PC version) the del editor removes leading
spaces immediately
after you entered them.

  
It appears that in your routines that restore from .apl or
  .xml files and ⎕FX you
  are (or were) retaining leading and trailing spaces.  That is
  the cause of all of these problems.


#2 does not conflict with #1.  You can store externally any
  way you like.  When reading it back you strip leading and
  trailing spaces.  This way the external format can be anything
  and the internal format is consistent.  No conflict.  ⎕CR
  doesn't have to do anything special because the format is
  already correct.  The del editor can format the lines nicely
  knowing it is starting with a consistent format (no leading or
  trailing spaces).


  

This is actually wrong. If we discard extra indentation spaces
entered by the user in the internal
format then they are lost as soon as you create the internal format.
This may on )LOAD, or on
⎕FX, or whereever.

If we would, as you propose, remove the user indentation from the
internal format, then
every )LOAD - modify - )SAVE (or )DUMP) sequence would inevitably
loose all user
indentation. Although the ∇-editor could, as you propose, construct
its own indentation,
but this would not keep any user indentation that differs from the
∇-editors indentation.

My proposal would be:

-  we add a DROP-INDENTATION setting in the preferences file that,
when set, discards
  all user indentation.

- ⎕CR will always drop leading and trailing blanks, regardless of
the DROP-INDENTATION
  setting

It would help me if you could summarize the rules for the formatting
of the ∇-editor,
it has been a while since I did that and I can't quite remember what
the rules were.

  
Thanks!


  

You're welcome.
Jürgen

  
Blake




  On Wed, Apr 8, 2020 at 2:04
PM Dr. Jürgen Sauermann 
wrote:
  
  Hi Blake,

I could live with 1. and 3. (which can be fixed in ⎕CR
alone).

However, 2. is not needed for this and it conflicts with 1.
because
at least the .xml files store the internal representation in
XML format.

The IBM ∇-editor is quite rigid in removing indentation but
I rather see that as a disadvantage. If you look into my C++
source files then you will notice that I have put quite some
effort into indentation. I strongly believe that good
indentation
leads to better readability of code and we should allow that
in APL as well.

Best regards,
Jürgen


On 4/8/20 8:31 PM, Blake McBride wrote:
> Hi Jürgen,
>
> How about this for a set of rules:
>
> 1.  Format .apl and .XML files any way you like.
>
> 2.  Regardless of how a function is instantiated (.apl,
.XML, ⎕FX, the
> del editor) the internal representation is all lines
left-justified. 
> Leading and trailing spaces for each line from the
source are stripped
> away.
>
> 3.  The del editor displays a function as it does now -
but the
> leading spaces are added by the del editor for display.
>
> This way, ⎕CR will be correct (left-justified) and the
del editor will
> display a consistent output regardless of how the
function was
> instantiated.
>
> Thanks!
>
> Blake
>
>
>
> On Wed, Apr 8, 2020 at 1:14 PM Dr. Jürgen Sauermann
> > wrote:
>
>     Hi Blake,
>

Re: Loading .apl files differes from .xml workspaces

[Blake McBride]

Hi Jürgen,

It seems to me that I fully understand the problem and I have a clear idea
of a clean solution.  On the other hand, it may be that I am failing to
articulate it, or I, in fact, do not know what I think I know.  I can't
tell which.

It also seems clear to me that adding yet another patch to the problem will
only needlessly increase the complexity and opportunity for failure - as
we've seen.  To wit, I am wholeheartedly against adding yet another
preference setting.

Perhaps you can give me a scenario in which my original algorithm would
fail.  That would help clarify an error in that algorithm for me.

Thanks!

Blake


On Thu, Apr 9, 2020 at 4:44 AM Dr. Jürgen Sauermann <
mail@jürgen-sauermann.de> wrote:

> Hi Blake,
>
> On 4/8/20 9:17 PM, Blake McBride wrote:
>
> Hi,
>
> As far as I am aware, the del editor displays functions as you do -
> including the indenting of labels and comments.  Yes, it helps looking at
> code.  I am certainly not suggesting changes to that!  The point is that
> the del editor can add that formatting when displaying a function.  That
> format should not be retained internally.  Keeping that format internally
> is causing all of these problems.
>
> Actually no. On my APL2 (PC version) the del editor removes leading spaces
> immediately
> after you entered them.
>
> It appears that in your routines that restore from .apl or .xml files and
> ⎕FX you are (or were) retaining leading and trailing spaces.  That is the
> cause of all of these problems.
>
> #2 does not conflict with #1.  You can store externally any way you like.
> When reading it back you strip leading and trailing spaces.  This way the
> external format can be anything and the internal format is consistent.  No
> conflict.  ⎕CR doesn't have to do anything special because the format is
> already correct.  The del editor can format the lines nicely knowing it is
> starting with a consistent format (no leading or trailing spaces).
>
> This is actually wrong. If we discard extra indentation spaces entered by
> the user in the internal
> format then they are lost as soon as you create the internal format. This
> may on )LOAD, or on
> ⎕FX, or whereever.
>
> If we would, as you propose, remove the user indentation from the internal
> format, then
> every )LOAD - modify - )SAVE (or )DUMP) sequence would inevitably loose
> all user
> indentation. Although the ∇-editor could, as you propose, construct its
> own indentation,
> but this would not keep any user indentation that differs from the
> ∇-editors indentation.
>
> My proposal would be:
>
> -  we add a DROP-INDENTATION setting in the preferences file that, when
> set, discards
>   all user indentation.
>
> - ⎕CR will always drop leading and trailing blanks, regardless of the
> DROP-INDENTATION
>   setting
>
> It would help me if you could summarize the rules for the formatting of
> the ∇-editor,
> it has been a while since I did that and I can't quite remember what the
> rules were.
>
> Thanks!
>
> You're welcome.
> Jürgen
>
> Blake
>
>
> On Wed, Apr 8, 2020 at 2:04 PM Dr. Jürgen Sauermann <
> mail@jürgen-sauermann.de> wrote:
>
>> Hi Blake,
>>
>> I could live with 1. and 3. (which can be fixed in ⎕CR alone).
>>
>> However, 2. is not needed for this and it conflicts with 1. because
>> at least the .xml files store the internal representation in XML format.
>>
>> The IBM ∇-editor is quite rigid in removing indentation but
>> I rather see that as a disadvantage. If you look into my C++
>> source files then you will notice that I have put quite some
>> effort into indentation. I strongly believe that good indentation
>> leads to better readability of code and we should allow that
>> in APL as well.
>>
>> Best regards,
>> Jürgen
>>
>>
>> On 4/8/20 8:31 PM, Blake McBride wrote:
>> > Hi Jürgen,
>> >
>> > How about this for a set of rules:
>> >
>> > 1.  Format .apl and .XML files any way you like.
>> >
>> > 2.  Regardless of how a function is instantiated (.apl, .XML, ⎕FX, the
>> > del editor) the internal representation is all lines left-justified.
>> > Leading and trailing spaces for each line from the source are stripped
>> > away.
>> >
>> > 3.  The del editor displays a function as it does now - but the
>> > leading spaces are added by the del editor for display.
>> >
>> > This way, ⎕CR will be correct (left-justified) and the del editor will
>> > display a consistent output regardless of how the function was
>> > instantiated.
>> >
>> > Thanks!
>> >
>> > Blake
>> >
>> >
>> >
>> > On Wed, Apr 8, 2020 at 1:14 PM Dr. Jürgen Sauermann
>> > mailto:mail@j%C3%BCrgen-sauermann.de>>
>> wrote:
>> >
>> > Hi Blake,
>> >
>> > the problem is that there are no rules for the formatting of the
>> > functions. I know
>> > that you had a few proposals in the past, but I haven't found a
>> > proper mental model
>> > of how to handle this.
>> >
>> > Please note that the .apl files are not only used to store
>> > workspaces, but also for
>> > creating a

Re: Loading .apl files differes from .xml workspaces

[Dr . Jürgen Sauermann]

  
  
Hi Blake,
  
  a simple example is this (written without testing since your
  algorithm is not yet implemented).
  
  )CLEAR

∇FOO
[1] 1
[2]  2
[3]   3
∇
  

∇FOO[⎕]
[1] 1
[2]  2
[3]   3
∇
  
)SAVE foo
  )CLEAR
  
  )LOAD foo

∇FOO[⎕]
  [1] 1
  [2] 2
  [3] 3
  ∇
  
  The file foo.xml (same for foo.apl) still
  contains the indented version of function FOO.
  
  However, )LOAD foo creates a new instace (i.e. internal
  version) of FOO which is, according to
  your algorithm NOT indented. Therefore the indentation is lost.
  
  Best regards,
  Jürgen
  

On 4/9/20 5:57 PM, Blake McBride wrote:


  
  
Hi Jürgen,
  
  
  It seems to me that I fully understand the problem and I
have a clear idea of a clean solution.  On the other hand,
it may be that I am failing to articulate it, or I, in fact,
do not know what I think I know.  I can't tell which.
  
  
  It also seems clear to me that adding yet another patch
to the problem will only needlessly increase the
complexity and opportunity for failure - as we've seen.  To
wit, I am wholeheartedly against adding yet another
preference setting.
  
  
  Perhaps you can give me a scenario in which my original
algorithm would fail.  That would help clarify an error in
that algorithm for me.
  
  
  Thanks!
  
  
  Blake


  



  On Thu, Apr 9, 2020 at 4:44
AM Dr. Jürgen Sauermann 
wrote:
  
  
 Hi Blake,
  
  On 4/8/20 9:17 PM, Blake McBride wrote:
  
  

  Hi,
  
  
  As far as I am aware, the del editor displays
functions as you do - including the indenting of
labels and comments.  Yes, it helps looking at
code.  I am certainly not suggesting changes to
that!  The point is that the del editor can add that
formatting when displaying a function.  That format
should not be retained internally.  Keeping that
format internally is causing all of these problems.
  
  

  
  Actually no. On my APL2 (PC version) the del editor
  removes leading spaces immediately
  after you entered them.
  

  It appears that in your routines that restore
from .apl or .xml files and ⎕FX you are (or
were) retaining leading and trailing spaces.  That
is the cause of all of these problems.
  
  
  #2 does not conflict with #1.  You can store
externally any way you like.  When reading it back
you strip leading and trailing spaces.  This way the
external format can be anything and the internal
format is consistent.  No conflict.  ⎕CR doesn't
have to do anything special because the format is
already correct.  The del editor can format the
lines nicely knowing it is starting with a
consistent format (no leading or trailing spaces).
  
  

  
  This is actually wrong. If we discard extra indentation
  spaces entered by the user in the internal
  format then they are lost as soon as you create the
  internal format. This may on )LOAD, or on
  ⎕FX, or whereever.
  
  If we would, as you propose, remove the user indentation
  from the internal format, then
  every )LOAD - modify - )SAVE (or )DUMP) sequence would
  inevitably loose all user
  indentation. Although the ∇-editor could, as you propose,
  construct its own indentation,
  but this would not keep any user indentation that differs
  from the ∇-editors indentation.
  
  My proposal would be:
  
  -  we add a DROP-INDENTATION setting in the preferences
  file that, when set, discards
    

Re: Loading .apl files differes from .xml workspaces

[Blake McBride]

Your example doesn't follow my rules.  I comment below in blue.

On Thu, Apr 9, 2020 at 11:55 AM Dr. Jürgen Sauermann <
mail@jürgen-sauermann.de> wrote:

> Hi Blake,
>
> a simple example is this (written without testing since your algorithm is
> not yet implemented).
>
> *)CLEAR*
>
> *∇FOO*
> *[1] 1*
> *[2]  *
> *2 **[3]*
> *   3 *
>
> *∇ *
>

Rule #2 forces all lines (from the previous function creation) to be
left-justified meaning that the display of the function (following this
line) would instead look like the last listing of this function you show.
e.g. they're all left justified and appear to be indented the same.  See
additional example further down.


>
>
>
>
>
>
>
>
>
>
> *∇FOO[⎕] [1] 1 [2]  2 [3]   3 ∇ )SAVE foo )CLEAR )LOAD foo *
> *∇FOO[⎕]*
> *[1] 1*
> *[2] *
> *2 **[3]*
> * 3 *
> *∇*
>

Here is what it would look like following my rules:

*)CLEAR*

*∇FOO*
*[1] 1*
*[2]  *
*2**[3]*
*   3*

*∇*




*∇FOO[⎕][1] 1[2] 2[3] 3∇*



>
> The file *foo.xm**l* (same for *foo.apl*) still contains the indented
> version of function *FOO*.
>
> However, *)LOAD* foo creates a new instace (i.e. internal version) of
> *FOO* which is, according to
> your algorithm NOT indented. Therefore the indentation is lost.
>
> Best regards,
> Jürgen
>
>
> On 4/9/20 5:57 PM, Blake McBride wrote:
>
> Hi Jürgen,
>
> It seems to me that I fully understand the problem and I have a clear idea
> of a clean solution.  On the other hand, it may be that I am failing to
> articulate it, or I, in fact, do not know what I think I know.  I can't
> tell which.
>
> It also seems clear to me that adding yet another patch to the problem
> will only needlessly increase the complexity and opportunity for failure -
> as we've seen.  To wit, I am wholeheartedly against adding yet another
> preference setting.
>
> Perhaps you can give me a scenario in which my original algorithm would
> fail.  That would help clarify an error in that algorithm for me.
>
> Thanks!
>
> Blake
>
>
> On Thu, Apr 9, 2020 at 4:44 AM Dr. Jürgen Sauermann <
> mail@jürgen-sauermann.de> wrote:
>
>> Hi Blake,
>>
>> On 4/8/20 9:17 PM, Blake McBride wrote:
>>
>> Hi,
>>
>> As far as I am aware, the del editor displays functions as you do -
>> including the indenting of labels and comments.  Yes, it helps looking at
>> code.  I am certainly not suggesting changes to that!  The point is that
>> the del editor can add that formatting when displaying a function.  That
>> format should not be retained internally.  Keeping that format internally
>> is causing all of these problems.
>>
>> Actually no. On my APL2 (PC version) the del editor removes leading
>> spaces immediately
>> after you entered them.
>>
>> It appears that in your routines that restore from .apl or .xml files and
>> ⎕FX you are (or were) retaining leading and trailing spaces.  That is
>> the cause of all of these problems.
>>
>> #2 does not conflict with #1.  You can store externally any way you
>> like.  When reading it back you strip leading and trailing spaces.  This
>> way the external format can be anything and the internal format is
>> consistent.  No conflict.  ⎕CR doesn't have to do anything special because
>> the format is already correct.  The del editor can format the lines nicely
>> knowing it is starting with a consistent format (no leading or trailing
>> spaces).
>>
>> This is actually wrong. If we discard extra indentation spaces entered by
>> the user in the internal
>> format then they are lost as soon as you create the internal format. This
>> may on )LOAD, or on
>> ⎕FX, or whereever.
>>
>> If we would, as you propose, remove the user indentation from the
>> internal format, then
>> every )LOAD - modify - )SAVE (or )DUMP) sequence would inevitably loose
>> all user
>> indentation. Although the ∇-editor could, as you propose, construct its
>> own indentation,
>> but this would not keep any user indentation that differs from the
>> ∇-editors indentation.
>>
>> My proposal would be:
>>
>> -  we add a DROP-INDENTATION setting in the preferences file that, when
>> set, discards
>>   all user indentation.
>>
>> - ⎕CR will always drop leading and trailing blanks, regardless of the
>> DROP-INDENTATION
>>   setting
>>
>> It would help me if you could summarize the rules for the formatting of
>> the ∇-editor,
>> it has been a while since I did that and I can't quite remember what the
>> rules were.
>>
>> Thanks!
>>
>> You're welcome.
>> Jürgen
>>
>> Blake
>>
>>
>> On Wed, Apr 8, 2020 at 2:04 PM Dr. Jürgen Sauermann <
>> mail@jürgen-sauermann.de> wrote:
>>
>>> Hi Blake,
>>>
>>> I could live with 1. and 3. (which can be fixed in ⎕CR alone).
>>>
>>> However, 2. is not needed for this and it conflicts with 1. because
>>> at least the .xml files store the internal representation in XML format.
>>>
>>> The IBM ∇-editor is quite rigid in removing indentation but
>>> I rather see that as a disadvantage. If you look into my C++
>>> source files then you will notice that I have put quite some
>>> effort into indentat

Re: Loading .apl files differes from .xml workspaces

[Blake McBride]

I checked IBM APL2.  They do what I am suggesting.  See the attached
screenshot.

--blake

On Thu, Apr 9, 2020 at 2:59 PM Blake McBride  wrote:

> Your example doesn't follow my rules.  I comment below in blue.
>
> On Thu, Apr 9, 2020 at 11:55 AM Dr. Jürgen Sauermann <
> mail@jürgen-sauermann.de> wrote:
>
>> Hi Blake,
>>
>> a simple example is this (written without testing since your algorithm is
>> not yet implemented).
>>
>> *)CLEAR*
>>
>> *∇FOO*
>> *[1] 1*
>> *[2]  *
>> *2 **[3]*
>> *   3 *
>>
>> *∇ *
>>
>
> Rule #2 forces all lines (from the previous function creation) to be
> left-justified meaning that the display of the function (following this
> line) would instead look like the last listing of this function you show.
> e.g. they're all left justified and appear to be indented the same.  See
> additional example further down.
>
>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *∇FOO[⎕] [1] 1 [2]  2 [3]   3 ∇ )SAVE foo )CLEAR )LOAD foo *
>> *∇FOO[⎕]*
>> *[1] 1*
>> *[2] *
>> *2 **[3]*
>> * 3 *
>> *∇*
>>
>
> Here is what it would look like following my rules:
>
> *)CLEAR*
>
> *∇FOO*
> *[1] 1*
> *[2]  *
> *2**[3]*
> *   3*
>
> *∇*
>
>
>
>
> *∇FOO[⎕][1] 1[2] 2[3] 3∇*
>
>
>
>>
>> The file *foo.xm**l* (same for *foo.apl*) still contains the indented
>> version of function *FOO*.
>>
>> However, *)LOAD* foo creates a new instace (i.e. internal version) of
>> *FOO* which is, according to
>> your algorithm NOT indented. Therefore the indentation is lost.
>>
>> Best regards,
>> Jürgen
>>
>>
>> On 4/9/20 5:57 PM, Blake McBride wrote:
>>
>> Hi Jürgen,
>>
>> It seems to me that I fully understand the problem and I have a clear
>> idea of a clean solution.  On the other hand, it may be that I am failing
>> to articulate it, or I, in fact, do not know what I think I know.  I can't
>> tell which.
>>
>> It also seems clear to me that adding yet another patch to the problem
>> will only needlessly increase the complexity and opportunity for failure -
>> as we've seen.  To wit, I am wholeheartedly against adding yet another
>> preference setting.
>>
>> Perhaps you can give me a scenario in which my original algorithm would
>> fail.  That would help clarify an error in that algorithm for me.
>>
>> Thanks!
>>
>> Blake
>>
>>
>> On Thu, Apr 9, 2020 at 4:44 AM Dr. Jürgen Sauermann <
>> mail@jürgen-sauermann.de> wrote:
>>
>>> Hi Blake,
>>>
>>> On 4/8/20 9:17 PM, Blake McBride wrote:
>>>
>>> Hi,
>>>
>>> As far as I am aware, the del editor displays functions as you do -
>>> including the indenting of labels and comments.  Yes, it helps looking at
>>> code.  I am certainly not suggesting changes to that!  The point is that
>>> the del editor can add that formatting when displaying a function.  That
>>> format should not be retained internally.  Keeping that format internally
>>> is causing all of these problems.
>>>
>>> Actually no. On my APL2 (PC version) the del editor removes leading
>>> spaces immediately
>>> after you entered them.
>>>
>>> It appears that in your routines that restore from .apl or .xml files
>>> and ⎕FX you are (or were) retaining leading and trailing spaces.  That
>>> is the cause of all of these problems.
>>>
>>> #2 does not conflict with #1.  You can store externally any way you
>>> like.  When reading it back you strip leading and trailing spaces.  This
>>> way the external format can be anything and the internal format is
>>> consistent.  No conflict.  ⎕CR doesn't have to do anything special because
>>> the format is already correct.  The del editor can format the lines nicely
>>> knowing it is starting with a consistent format (no leading or trailing
>>> spaces).
>>>
>>> This is actually wrong. If we discard extra indentation spaces entered
>>> by the user in the internal
>>> format then they are lost as soon as you create the internal format.
>>> This may on )LOAD, or on
>>> ⎕FX, or whereever.
>>>
>>> If we would, as you propose, remove the user indentation from the
>>> internal format, then
>>> every )LOAD - modify - )SAVE (or )DUMP) sequence would inevitably loose
>>> all user
>>> indentation. Although the ∇-editor could, as you propose, construct its
>>> own indentation,
>>> but this would not keep any user indentation that differs from the
>>> ∇-editors indentation.
>>>
>>> My proposal would be:
>>>
>>> -  we add a DROP-INDENTATION setting in the preferences file that, when
>>> set, discards
>>>   all user indentation.
>>>
>>> - ⎕CR will always drop leading and trailing blanks, regardless of the
>>> DROP-INDENTATION
>>>   setting
>>>
>>> It would help me if you could summarize the rules for the formatting of
>>> the ∇-editor,
>>> it has been a while since I did that and I can't quite remember what the
>>> rules were.
>>>
>>> Thanks!
>>>
>>> You're welcome.
>>> Jürgen
>>>
>>> Blake
>>>
>>>
>>> On Wed, Apr 8, 2020 at 2:04 PM Dr. Jürgen Sauermann <
>>> mail@jürgen-sauermann.de> wrote:
>>>
 Hi Blake,

 I could live with 1. and 3. (which can be fixed in ⎕CR alone).

 However, 2. is not needed f