John Meacham <[EMAIL PROTECTED]> wrote,
> 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 complier 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.
Yes, I think, I agree with you.
> * there is no Byte type for people writing new libraries, each
> person who writes a library which works on Byte streams must come
> up with their own kludge, oftentimes this causes needless
> conflicting namespaces, and even more often it is not strictly
> portable. a common solution is to assume a Char is
> a byte,
[..]
I think, Word8 really is our Haskell byte for now, given
that it is used by the low-level foreign function interface
(FFI). However, introducing a type synonym `Byte' or
`Octet' (as you propose) is probably a nice idea - after all,
we also have FilePath.
> 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.
Do you have an implementation for your API? The best thing
to see whether such a proposal works and gets accepted is
IMHO to code it up and give it to people. If you implement
it using the FFI, it will run on ghc and nhc and on Hugs
when finally somebody goes to the trouble of implementing
the FFI there.
Cheers,
Manuel
