Re: Loading .apl files differes from .xml workspaces

[Dr . Jürgen Sauermann]

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
> <mail@jürgen-sauermann.de <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 apl source files (they are my default way of writing apl
>     code). Therefore
>     formatting in a somewhat readable format is also an aspect
>     concerning .apl files.
>
>     As far as I can see the only real question is how leading spaces
>     shall be handled.
>     This needs to be clarified for:
>
>     1. the ∇-editor
>     2. ⎕CR
>     3. )SAVE/LOADed files
>     4. )DUMP/LOADed files
>
>     If you could come up with set of rules how to handle this in a
>     consistent
>     way (and satisfying everybody's requirements), then I can try to
>     implement
>     them.
>
>     I am not a day-to-day user of APL2, so I can't really tell how
>     that one is/was
>     supposed to work. My first version of the GNU APL ∇-editor came
>     from a vague
>     recollection of the ∇-editor in APL68000 back in the 1980s.
>
>     It is true that the way functions look depends on how the files
>     look like. But that
>     is on purpose. Otherwise you would loose leading spaces in the
>     function text.
>     Ig the ∇-editor would remove them then I would consider that more
>     as a fault
>     than a feature.
>
>     Best regards,
>     Jürgen
>
>
>     On 4/8/20 7:30 PM, Blake McBride wrote:
>>     Thanks.  While it appears to work, it's clearly wrong.  The
>>     formatting is still being done at the wrong place.  The way I
>>     discovered this is to load a .apl file from a prior version of
>>     GNU APL.  When I list the function, it's wrong.  So, GNU APL is
>>     depending on the format in the file rather than having the del
>>     editor format it.  For example:
>>
>>           )load Utils.apl
>>     DUMPED 2019-10-27  12:10:43 (GMT-6)
>>           ∇Pin[⎕]∇
>>         ∇
>>     [0]   n←v Pin q;m;t
>>     [1]    ⍝ Input one or more numbers
>>     [2]    ⍝ v[1] = minimum value (inclusive)
>>     [3]    ⍝ v[2] = maximum value (inclusive)
>>     [4]    ⍝ v[3] = numeric increment (i.e. 1 = integer)
>>     [5]    ⍝ Remining values are optional
>>     [6]    ⍝ v[4] = minimum number of numbers
>>     [7]    ⍝ v[5] = maximum number of numbers
>>     [8]    ⍝ v[6] = default value of empty entry (or ¯1 means no default)
>>     [9]    ⍝ v[7+] = numbers the entered value cannot be
>>     [10]   ⍝ q is the prompt
>>     [11]   t←⍳0
>>     [12]   ⍎(3=⍴v)/'v←v,1 1'
>>     [13]   m←v[5]
>>     [14]   LP:→(m=⍴t)/EN3
>>     [15]   EN1:→(EHN n←CS PI q,'?')/0,0,EN2
>>     [16]   →(v[⍳5]Lck n)/EN1
>>     [17]   n[Omega n='-']←'¯'
>>     [18]   →(∨/(n←⍎n)∈6↓v)/ER1
>>     [19]   t←t,n
>>     [20]   v[5]←v[5]-⍴,n
>>     [21]   →LP
>>     [22]   EN2: →(0≠⍴t)/EN3
>>     [23]   →(5=⍴v)/0
>>     [24]   →(v[6]=¯1)/0
>>     [25]   t←v[,6]
>>     [26]   EN3:⍎'n←',((m=1)/'''''⍴'),'t'
>>     [27]   →0
>>     [28]   ER1:→EN1 ∆ ER(⍕n), ' already exists; Please reenter.'
>>         ∇
>>           
>>     Thanks!
>>
>>     Blake
>>
>>
>>
>>     On Wed, Apr 8, 2020 at 10:58 AM Dr. Jürgen Sauermann
>>     <mail@jürgen-sauermann.de <mailto:mail@j%C3%BCrgen-sauermann.de>>
>>     wrote:
>>
>>         Hi Blake,
>>
>>         thanks, hopefully fixed in *SVN 1256*.
>>
>>         Best Regards,
>>         Jürgen
>>
>>
>>
>>         On 4/8/20 4:18 PM, Blake McBride wrote:
>>>         Also, and further showing the point that the formatting is
>>>         occurring at the wrong place:
>>>
>>>               ⎕CR 'ABC'
>>>         ABC                
>>>          x←4                
>>>          EN1: Y←5          
>>>          Z←7                
>>>          ⍝ THIS IS A COMMENT
>>>          Z←5  
>>>
>>>         Those space characters before each line should never happen
>>>         but does when the file is loaded from a .APL file.
>>>
>>>         Thanks!
>>>
>>>         Blake
>>>                       
>>>
>>>
>>>
>>>
>>>         On Wed, Apr 8, 2020 at 8:56 AM Blake McBride
>>>         <address@hidden <mailto:address@hidden>> wrote:
>>>
>>>             Lastly, I should mention that the first display of ABC
>>>             is the correct one, and the one that matched IBM APL.
>>>
>>>             Thanks.
>>>
>>>             Blake
>>>
>>>
>>>             On Wed, Apr 8, 2020 at 8:46 AM Blake McBride
>>>             <address@hidden <mailto:address@hidden>> wrote:
>>>
>>>                 Greetings,
>>>
>>>                 Echoing some thoughts I've had on this subject,
>>>                 given the trouble we've had with function
>>>                 formatting over the years between the del editor
>>>                 and ⎕CR, I get the impression that function
>>>                 formatting is occurring at the wrong place.  I think
>>>                 internally functions should be stored left-justified
>>>                 always.  The del editor would then be the one adding
>>>                 the formatting for comments and labels.  This way
>>>                 there wouldn't be ongoing problems between the del
>>>                 editor, save, dump, and ⎕CR.
>>>
>>>                 Thanks.
>>>
>>>                 Blake
>>>
>>>                 On Wed, Apr 8, 2020 at 8:36 AM Blake McBride
>>>                 <address@hidden <mailto:address@hidden>>
>>>                 wrote:
>>>
>>>                     Greetings,
>>>
>>>                     Look at the formatting.  In particular look at
>>>                     how the lines with labels and comments are
>>>                     indented.  They are indented differently
>>>                     depending on whether the file is saved or dumped.
>>>
>>>                           ∇ABC[⎕]∇
>>>                         ∇
>>>                     [0]   ABC
>>>                     [1]   X←4
>>>                     [2]  EN1: Y←5
>>>                     [3]   Z←7
>>>                     [4]  ⍝ THIS IS A COMMENT
>>>                     [5]   Z←5
>>>                         ∇
>>>                           )save test
>>>                     2020-04-08  08:30:48 (GMT-5)
>>>                           )dump test
>>>                     2020-04-08  08:30:52 (GMT-5)
>>>                           )load test    
>>>
>>>                     WARNING: filename /home/blake/workspaces/test
>>>                         is ambiguous because another file
>>>                         /home/blake/workspaces/test.apl
>>>                         exists as well. Using the first.
>>>
>>>                     SAVED 2020-04-08 08:30:48 (GMT-5)
>>>                           ∇ABC[⎕]∇
>>>                         ∇
>>>                     [0]   ABC
>>>                     [1]   X←4
>>>                     [2]  EN1: Y←5
>>>                     [3]   Z←7
>>>                     [4]  ⍝ THIS IS A COMMENT
>>>                     [5]   Z←5
>>>                         ∇
>>>                           )load test.apl
>>>                     DUMPED 2020-04-08  08:30:52 (GMT-5)
>>>                           ∇ABC[⎕]∇
>>>                         ∇
>>>                     [0]   ABC
>>>                     [1]    X←4
>>>                     [2]    EN1: Y←5
>>>                     [3]    Z←7
>>>                     [4]    ⍝ THIS IS A COMMENT
>>>                     [5]    Z←5
>>>                         ∇
>>>
>>>                     Thanks!
>>>
>>>                     Blake
>>>
>>
>