Re: [Bug-apl] #PW and #TC[2]

[Juergen Sauermann]

Hi Brian,

yes. The  line wrapping is taking place before a value is being printed.

There is no such thing as a "current column". The reason is that APL
output is fairly "column oriented" which means that the start of
columns is supposed to be the same screen column, even across
higher dimensions. And the IBM language reference also suggests that ⎕PW
relates to the column of the value being printed as opposed to the column where
the cursor stands when the next item on a line is being printed  (p. 318):

Display of an array R wider than the value of ⎕PW is folded at or
just before the column specified by ⎕PW.

and:

If ⎕PW is small and ⎕PP is large, the display of some complex numbers in a
simple array may extend beyond ⎕PW. If ⎕PW is at least 13+2×⎕PP, individual
numbers in a simple array do not exceed ⎕PW. Numbers in a nested array may be
split with any value of ⎕PP.

It is generally problematic to use characters from ⎕TC (or, for that matter,
ESC sequences) in APL output. You can do it, but the way the output looks
like is very platform dependent and can vary a lot even on the same platform.

For example (GNU APL on Ubuntu):

      'AAA',⎕TC[2],'BBB'
AAA
   BBB

      )HOST stty -a
speed 38400 baud; rows 24; columns 80; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread -clocal -crtscts
ignbrk -brkint ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc -ixany -imaxbel iutf8
opost -olcuc ocrnl onlcr -onocr onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig -icanon -iexten -echo echoe echok -echonl -noflsh -xcase -tostop -echoprt
echoctl echoke

0

And then (same machine, CR overrides AAA):

            'AAA',⎕TC[2],'BBB'
BBB
            )HOST stty -a
speed 38400 baud; rows 24; columns 80; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R;
werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread -clocal -crtscts
ignbrk -brkint ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc -ixany -imaxbel iutf8
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig -icanon -iexten -echo echoe echok -echonl -noflsh -xcase -tostop -echoprt
echoctl echoke

0

Suppose we would reset the non-existing column counter when CR is encountered, the next
problem will be NL (which may or may not imply CR), TABs (how wide are they?), and
finally those ESC sequences that are positioning the cursor.

This all looks very much like a Pandorra box that I would prefer to remain closed.

I am aware that GNU APL behaves differently than IBM APL2 in this regard, but there is no usable
formal description of how the output formatting is supposed to work. Also the examples given by IBM
in the language reference manual and the examples (also given by IBM) in the ISO standard
are sometimes contradicting when it comes to output formatting. I have tried my best to follow the
brief explanations in the IBM language reference manual, but they are leaving out a lot of details.
I would also assume that IBM APL2 behaves differently on different platforms.

/// Jürgen


interpret those ESC sequences that modify the column

On 02/21/2017 07:37 PM, McGuinness, Brian wrote:

Automatic line wrapping doesn't seem to
take into account the wrapping caused by
printing newline characters (#TC[2]).  So
if I display a character vector that
includes newline characters, I get extra
line wraps.

APL should reset its "current column"
value to 1 whenever a newline is printed
in order to avoid this extra line wrapping.

--- Brian