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