Re: Loading .apl files differes from .xml workspaces

[Dr . Jürgen Sauermann]

I know. And I believe it is wrong.

-- Jürgen


On 4/9/20 11:22 PM, Blake McBride wrote:
> I checked IBM APL2.  They do what I am suggesting.  See the attached
> screenshot.
>
> --blake
>

Re: Loading .apl files differes from .xml workspaces

[Elias Mårtenson]

Wrong may be an inappropriate word, but I agree that it's a pretty stupid
thing to do. If a user formats the code in a certain way, I'd assume he
does it because he wants it that way.

It's one of the reasons I dislike Go. It automatically reformats your code
when compiling.

On Fri, 10 Apr 2020, 18:16 Dr. Jürgen Sauermann, 
wrote:

> I know. And I believe it is wrong.
>
> -- Jürgen
>
>
> On 4/9/20 11:22 PM, Blake McBride wrote:
> > I checked IBM APL2.  They do what I am suggesting.  See the attached
> > screenshot.
> >
> > --blake
> >
>
>
>

Re: Loading .apl files differes from .xml workspaces

[Blake McBride]

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
>

Re: Loading .apl files differes from .xml workspaces

[Blake McBride]

Retaining a user's formatting may or may not be a good thing, but it's not
APL if it does so.  Languages such as C, C++, Java, etc. are Algol-style
languages.  They retain the user's format.  APL is not.

On Fri, Apr 10, 2020 at 6:33 AM Elias Mårtenson  wrote:

> Wrong may be an inappropriate word, but I agree that it's a pretty stupid
> thing to do. If a user formats the code in a certain way, I'd assume he
> does it because he wants it that way.
>
> It's one of the reasons I dislike Go. It automatically reformats your code
> when compiling.
>
> On Fri, 10 Apr 2020, 18:16 Dr. Jürgen Sauermann, 
> wrote:
>
>> I know. And I believe it is wrong.
>>
>> -- Jürgen
>>
>>
>> On 4/9/20 11:22 PM, Blake McBride wrote:
>> > I checked IBM APL2.  They do what I am suggesting.  See the attached
>> > screenshot.
>> >
>> > --blake
>> >
>>
>>
>>

Re: Loading .apl files differes from .xml workspaces

[Dr . Jürgen Sauermann]

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

  

  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.


  

  
 
  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 wil

Re: Loading .apl files differes from .xml workspaces

[Blake McBride]

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 fro

Re: Loading .apl files differes from .xml workspaces

[Dr . Jürgen Sauermann]

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

Re: Loading .apl files differes from .xml workspaces

[Blake McBride]

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

Re: Loading .apl files differes from .xml workspaces

[Dr . Jürgen Sauermann]

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