|
From: | Blake McBride |
Subject: | Re: [Bug-apl] Function list display anomalies |
Date: | Wed, 14 May 2014 09:04:57 -0500 |
Hi Blake,
thanks, fixed in SVN 265.
/// Jürgen
On 05/13/2014 05:07 PM, Blake McBride wrote:
In GNU APL, when you list a function via:
∇fun[⎕]∇
the format of the returned output has several problems (inconsistencies with respect to the IBM documentation). Some of the differences are small but it would be nice of they were corrected. One difference is important in my opinion. I will use the following function as an example:
∇myfun[⎕]∇[0] z←myfun x[1] ⍝ sample function[2] →(x < 5)/EN1[3] z←x+10[4] →END[5] EN1:x←x[6] END:
1. The first problem (and the one I feel is important) is that a closing ∇ is not shown. The reason this is important is to avoid confusion over whether you are seeing the entire function definition or not. Without the closing ∇ you are not sure if you see the whole function, or the display is being chopped off early.
2. To be consistent, an opening ∇ should be shown.
3. There should be 3 spaces between the line number designation (i.e. [4]) and the code not 1. This is important because of the following item.
4. Code lines that begin with ⍝ or a line label are separated from the line number designation by 2 spaces rather than 3. This is to make those lines stick out to the eye. It makes the code easier to read.
5. When the line numbers go from one digit to two, the space between the line number designation and the code is reduced by one. A more accurate way of describing this is that the line number designation always takes up 5 character positions. Doing this, code is always consistently aligned regardless of the number of digits in the line number designation.
Taking all the above into account, this is what should be displayed:
∇myfun[⎕]∇∇[0] z←myfun x[1] ⍝ sample function[2] →(x < 5)/EN1[3] z←x+10[4] →END[5] EN1:x←x[6] END:∇
I would imagine that these changes are trivial, but I think they would make the system much more consistent. The following are some references for you to verify my findings:
IBM APL2 Programming: Language Reference, page 346ibid, page 383
Thanks.
Blake
[Prev in Thread] | Current Thread | [Next in Thread] |