Hi Blake, i am getting this:
* )clear** **CLEAR WS** ** ∇abc** **[1] 1** **[2] 2** **[3] 3** **[4] [⎕]** ** ∇** **[0] abc** **[1] 1** **[2] 2** **[3] 3** ** ∇** **[4] ∇* I suppose that either your preferences file is wrong (e.g. wrong profile), or not read: (check with apl -l 37), or your recompile has not caught all dependencies. Best Regards, Jürgen On 4/10/20 6:45 PM, Blake McBride wrote: > Thanks! > > I have: DISCARD-INDENTATION Yes > in my ~/.gnu-apl/preferences file, however: > > ∇abc > [1] 1 > [2] 2 > [3] 3 > [4] [⎕] > ∇ > [0] abc > [1] 1 > [2] 2 > [3] 3 > ∇ > [4] ∇ > ∇abc[⎕]∇ > ∇ > [0] abc > [1] 1 > [2] 2 > [3] 3 > ∇ > > As you can see, the indents are still there. > > Thanks. > > Blake > > > On Fri, Apr 10, 2020 at 11:13 AM Dr. Jürgen Sauermann > <mail@jürgen-sauermann.de <mailto:mail@j%C3%BCrgen-sauermann.de>> wrote: > > Hi Blake > > to conclude the discussion I made the following changes (*SVN 1259*): > > 1. *⎕CR* will always remove unnecessary leading and trailing spaces. > > Unfortunately this deprives the fans of indentation of any possibility > to obtain their loved indented version back into APL. Therefore: > > 2. The unmodified (indented) version of a defined function can now be > obtained with dyadic *37 ⎕CR* instead of monadic *⎕CR*. > > 3. Indentation can be controlled with preference > *DISCARD-INDENTATION*. > If set to *Yes* then (hopefully) all indentation is rigorously > removed, and regardless > of whether the function is created via *)LOAD*, the *∇*-editor, > or *⎕FX*. > > Users should be warned that setting *DISCARD-INDENTATION *might also > (negatively) affect the content of multi-line strings in defined > functions and > maybe *⎕INP*. > > At this point I am not sure if all cases were properly caught, so > please test > this preference extensively and let me know if it fails. > > Best Regards, > Jürgen > > > > On 4/10/20 2:52 PM, Blake McBride wrote: >> Hi Jürgen, >> >> Thanks for your response! See mine below. >> >> On Fri, Apr 10, 2020 at 7:31 AM Dr. Jürgen Sauermann >> <mail@jürgen-sauermann.de <mailto:mail@j%C3%BCrgen-sauermann.de>> >> wrote: >> >> Hi Blake, >> >> see below. >> >> Jürgen >> >> On 4/10/20 1:34 PM, Blake McBride wrote: >>> Hi Jürgen, >>> >>> Please see my response in-line below. >>> >>> On Fri, Apr 10, 2020 at 5:07 AM Dr. Jürgen Sauermann >>> <mail@jürgen-sauermann.de >>> <mailto:mail@j%C3%BCrgen-sauermann.de>> wrote: >>> >>> Hi Blake, >>> >>> I see what you are after. >>> >>> You said earlier that you don't care how functions are >>> stored externally. >>> At the same time you want the internal representation >>> to not contain >>> additional spaces. >>> >>> However, the internal representation is what is being >>> stored on )SAVE >>> or )DUMP. Therefore your requirement on the internal >>> representation >>> prevents the functions to be store in a way that >>> preserves the indentation >>> inserted by the user. >>> >>> >>> First, I have never wanted to preserve the indentation >>> provided by the user. In fact, I explicitly do not. APL is >>> not an ALGOL-family language. >>> >> This is the core of the disagreement between you and me. >> You don't and I do. >> >> >> Yes, indeed. I just realized that with my last email. Before >> that, I couldn't understand why you were saying what you were saying. >> >> >>> Second, there is, in this case, little relationship between >>> the internal representation and the format of the save/dump >>> files. You can store functions internally left justified >>> and format them for a save/dump any way you like - just like >>> the del editor. >>> >>> >>> >>> In other words, if I would folllow your requirement on >>> the internal >>> representation, then I have no choice than to follow >>> suit in the external >>> representation. >>> >>> >>> Not at all. You have C++ functions that write out the APL >>> code. Those C++ functions can provide whatever format you like. >>> >> Yes, I have C++ functions that write out the APL code. But >> the argument of the >> function that writes an APL function in .apl or .xml format >> is the internal representation. >> There is no other representation once ⎕FX or the ∇-editor >> have done their work. >> If we discard additional spaces in the internal >> representation then they gone >> forever and there is no way to get them back. >> >> >> Agreed. I see the problem. >> >> >> >>> >>> In yet other words, you want the "leading-space-less" >>> representation >>> to be used everywhere: internally, in the ∇editor, in >>> ⎕CR, and in .apl >>> and .xml files. >>> >>> >>> That's not what I am saying. You store the functions >>> internally left-justified. When you do [⎕] in the del >>> editor, the del editor adds the desired formatting at that >>> point. So, the user will see the comment and label lines >>> indented differently as they should be when the user sees >>> the function from the del editor. >>> >> Its not what you are saying but it is the immediate >> consequences of it, >>> >>> >>> IMHO the fact that the ∇-editor removes indentation is a >>> nuisance >>> rather than a feature. You are used to it and want it >>> back. The >>> GNU APL mechanism for solving this kind of differences >>> in opinions >>> is preferences files and not fundamental changes of >>> principles >>> of the implementation. >>> >>> >>> APL is what is defined by IBM and the standard. You can do >>> whatever you like - but it won't be APL. I have several >>> years working with IBM APL. I've also used several other >>> APL's and, with very few exceptions, they follow the IBM >>> standard. I have a keen eye and am merely trying to assist. >>> >> And I appreciate that. >> >>> As a side note, what started all of this a few years ago is >>> that the way you were handling function spaces actually >>> broke code I had. My APL Editor uses ⎕CR to get at a >>> function for editing purposes. I had used that editor >>> professionally for years on IBM APL, TSR APL, APL 68000, >>> Harris APL, and others. They all provided the function >>> left-justified. Your ⎕CR did not. >>> >> As I said earlier, I will fix ⎕CR to not show leading spaces >> and independently of the >> user's preference file. That does not, however, imply a >> change of the internal >> representation. The internal representation plays a role in >> more places than those >> that the APL user sees and therefore fixing ⎕CR is far >> simpler than changing the >> internal implementation. >> >> >> Although that does fix ⎕CR, it still causes other problems that >> initiated this whole second round of discussions. In other >> words, I think your efforts to support your preference is causing >> a rippling effect in other areas - like the ⎕CR problem. >> >> >>> >>> I will be happy to make GNU APL behave as you prefer, >>> but I refuse >>> to make it behave in a way that I do not prefer. >>> Especially your >>> Rule #2 below is what I would hate to see. IMHO an >>> editor should >>> change the text entered by a user as little as possible, >>> even if the >>> old IBM APL2 editor did so. >>> >>> >>> My suggestions have nothing to do with my preferences. This >>> is the way all APL's I've used work. >>> >>> If you have a non-APL preference, it's your APL, support >>> what you like. I am merely providing feedback on difference >>> from the standard. It's up to you to follow that or support >>> your personal >> Neither the APL standard (ISO) nor IBM's APL2 Language >> reference is specific concerning >> leading spaces in tge ∇-editor. IBM itself has taken quite >> some freedom to implement the >> ∇-editor differently on its different platforms. Therefore >> the "standard" that you refer to >> seems to be a common behaviour of several implementations. >> >> >> Although I agree, it is "common behavior of several >> implementations", it is also what long-time APL users expect. >> When we don't see it, we start to question what else is >> different. Additionally, as we've already seen, those changes >> have unintended consequences. >> >> >>> preferences. Perhaps I can recommend this: >>> >>> 1. provide the standard out-of-the-box >>> 2. add a preferences option to support your preference, and >>> perhaps others, as an option >>> >>> This way when people who know APL download and install >>> GNU-APL, they'll see what they expect to see. When they dig >>> into GNU APL they'll see the option and make a personal >>> decision. >>> >> I will do something along those lines. However, to prevent >> existing GNU APL users from >> surprises (i.e. for the sake of backward compatibility), I >> will make the current behaviour >> the default. >> >> >> I deeply appreciate all that you have done. It is my opinion >> that, in the long run, you will have played a very major role in >> the survival of APL. I feel that a small change here and a small >> change there over a long period of time will morph APL into >> something else. That is one of the reasons I don't want change. >> >> Thanks! >> >> Blake >> >> >
