Hi Elias,
I used ⎕CR instead of ⎕UCS because I believe it is more "standard" and also
has a different semantics in GNU APL (mix of integer and char, etc).
⎕UCS was
more for IBM APL2 compatibility.
Also, I try to keep the number of libraries to a minimum. Almost every
library I used so
far in GNU APL (included the curses that you proposed earlier if I
remember correctly)
has fired back on some platform (not installed, no header files, not
compatible, ...).
The UTF8 encoding was a thing that I had already on my TODO list, I was
just lacking time to do it.
As you can see in QuadFunctions.cc, each of the two new encoding took
only 8 lines of code, so the
integration of a new library in C++ and autoconf would have been longer.
And, as I stated earlier, I am not fond of too many non-standard
extensions. Some make sense, but
arbitrary encodings should be in native functions rather than ⎕xx. The
⎕CR is a bit different because
I started it before native functions, these days I would probably extend
FILE_IO or some MISC library.
/// Jürgen
On 04/28/2014 03:50 PM, Elias Mårtenson wrote:
What do you think of the idea of supporting arbitrary encodings using
dyadic ⎕UCS? I'd be happy to implement it. Although, perhaps you don't
want to add a dependency on iconv?
Regards,
Elias
