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> 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> 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
