I don't have a problem with all the character encoding infrastructure and whatnot, but it makes sense logically in an Language API to provide access to the lowest level of IO that is possible, whether the more advanced operations themselves are implemented in Haskell or specially by the compiler is an implementation issue and an optimization. the point is that if i wanted to write my own character handling code in Haskell there is no way to because the base IO primitives (of reading and writing bytes) are hidden below the current IO API and 'implementation defined' behavior.

My proposal was meant to satisfy three different needs which are not currently met by the Haskell IO primitives:

without these properties it is almost impossible to write any 'real' application in Haskell, mainly because most programs need to do at least one interesting thing where interesting means interact with the outside world in a new/undefined manner, the programmer needs to know his Haskell program or library will work as expected across platforms.

the solution needs not be the best or even the most efficient, it merely needs to solve these problems in a way that is not inconsistent with the current language APIs and definition and be not difficult to implement for any compiler writer. the reason is that it is unclear at this time what a completely efficient API would look like, different compilers have their own efficient IO extensions which people can use if they are that concerned, but it needs to be possible to write portable programs and libraries that need the above properties independent of the above. that is what i designed my API to be, simply implemented on top of the current compilers private binary APIs yet simple and modeled after the current Prelude functions so as to mesh well with existing codebase and mindshare.