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> 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> 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 <blake1...@gmail.com> 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 <blake1...@gmail.com> >>> 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 <blake1...@gmail.com> >>>> 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 >>>>> >>>>> >> >
