Re: [Bug-apl] Incorrect encoding in ATF files.

[Kacper Gutowski]

On 2014-01-18 13:04:41, Juergen Sauermann wrote:
> The strategy of GNU APL is to be tolerant on input and accept all of
> these variants
> on input (keyboard or script files) and to keep it internally so
> that the user should
> not see a difference. Eg. One user can use ∈ while another user
> could use ∊ and both would
> see "their" characters.

It's very good that it accepts many possible variants but I'm not sure
that keeping them around is worth the effort.  It's nice but I certainly
wouldn't be surprised or complain if they were just normalized to some
subset GNU APL likes as long it can be displayed on my terminal.
The latest version from SVN leaks its preferred variant for example when
reporting syntax error as in:
      *
SYNTAX ERROR
      ⋆
      ^
And I don't see any problem with this.

> The )IN and )OUT commands that are dealing with .ATF files are
> currently lacking this kind
> of tolerance, but I will add this soon (the )IN command will always
> map to GNU APL's choice of
> character, but )OUT will become more tolerant).

Thank you in advance for fixing this.  Obviously )IN doesn't have much
choice, the only problem is with )OUT which I would expect to appropriately
map everything GNU APL accepts.

Regarding the )IN fault tolerance, it seems that some APLs treat quad-
names case-insensitively and, e.g., files exported from Dyalog APL use
lower case ⎕ucs, ⎕fx, ⎕io, etc (in function definitions and character
arrays because a record ⎕IO←1 itself is upper-case).  Currently these
can't be imported by GNU APL without manually upper-casing it (one also
has to remove all the unknown records like ⎕RTL←0 for )IN to succeed).

-k