Re: [Bug-apl] ⎕TC presents as Unix, not APL

[Juergen Sauermann]

Hi David,

I believe that the IBM specified behavior is only achievable (if at all)
with platform specific (actually terminal specific) APL variants. The header
on page 335 says:

⎕TC Contains a three-item character vector of terminal control characters:
 ⎕TC[1]—backspace
 ⎕TC[2]—new line (return)
 ⎕TC[3]—line feed

This is what GNU APL has implemented, taking ASCII verbatim:

      ⎕UCS ⎕TC
8 13 10

These numbers come from ASCII rather than from Unix. Then the purpose of ⎕TC is explained:

Use ⎕TC rather than ⎕AV to avoid system dependencies (because the
order of ⎕AV is different in different APL implementations).

This assumes that the same character - take newline as an example - may be located at different positions
of the ⎕AV but behaves identically otherwise. But then the display vs. typewriter example shows that this is
not the case. I would add the Windows vs. Unix example where newline may or may not imply a carriage
return.

If we would use curses as Elias suggested earlier that we could easily violate the 'three-item character vector'
spec in the header.

Taking this all together tells me that ⎕TC, which was mainly provided for IBM code compatibility and not for real
use in new programs, is a stone-age left-over (I remember having it seen in classical APL but never used) should
remain as is.

Thank you nevertheless for pointing this out!
/// Jürgen



On 05/31/2014 08:50 PM, David B. Lamkins wrote:

See IBM Reference, page 335.

⎕tc[2] and ⎕tc[3] differ from the IBM-specified behavior, presenting as
Unix format effectors rather than as APL format effectors.

In particular, APL specifies that ⎕tc[2] should advance the print
position to the start of the next line and ⎕tc[3] should advance the
print position downward one line while retaining the current column
position.

The current behavior of ⎕tc[1] is acceptable according to the IBM
Reference.