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

[Juergen Sauermann]

Hi Kacper,

if I remember correctly then I changed something from ∈ to ∊ recently
following a suggestion from a user (to be more compatible with some other
APL interpreter).

Unfortunately different interpreters use different characters for the 
same function
and there seems to be no commonly agreed character set.

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.

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


/// Jürgen


On 01/18/2014 05:42 AM, Kacper Gutowski wrote:
> >        ⎕FX 'test' '⋄'
> I just realized that I entered ⋄ U+22C4 while GNU APL defaults
> to ◊ U+25CA and the later is correctly encoded as d8 in ATF.
> Looks like ∊/∈ also suffers the same problem while writing to ATF file.
>
>
> So I must ask this (loosely related) question now.
> Is there any specific reason why characters different than usual
> were chosen as default? Or is just my notion of what's usual flawed?
>
> For example both NARS2000 and Dyalog's APL/W (as I played only with
> those two before) use U+22C4 for diamond; APL/W doesn't even accept
> U+25CA as a valid token.  Likewise they both use ∊ U+220A and don't
> accept U+2208.  The later character ∈ is also missing from popular
> APL385 Unicode font.
>
> Well, on the other hand I like that GNU APL uses ∼ and ⋆ rather than
> plain ~ and * as this seems ‘more correct’ and in some fonts looks
> better; even if it's less compatible.
>
> -k