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