You are right. I'll write a native library that hooks into libiconv later. :-)
Regards, Elias On 28 April 2014 22:43, Juergen Sauermann <[email protected]>wrote: > 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 >> >> >> >
