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
∇
∇FOO[⎕]
[1] 1
[2] 2
[3] 3
∇
)SAVE foo
)CLEAR
)LOAD foo
∇FOO[⎕]
[1] 1
[2] 2
[3] 3
∇
The file foo.xml (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!
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.
You're welcome.
Jürgen
Blake
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
>>> <address@hidden
<mailto:address@hidden>>
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
>>> <address@hidden
<mailto:address@hidden>>
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
>>> <address@hidden
<mailto:address@hidden>>
>>> 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
>>>
>>
>
|