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 >>> <[email protected] <mailto:[email protected]>> 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 >>> <[email protected] <mailto:[email protected]>> 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 >>> <[email protected] <mailto:[email protected]>> >>> 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 >>> >> >
