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