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> 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. 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. > > 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. > > 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. 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. > > 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 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. Thanks! Blake > > Best Regards, > Jürgen >
