Text I/O library proposal, first draft

[Ben Rudiak-Gould]

On Thu, 31 Jul 2003, John Meacham wrote:
> On Thu, Jul 31, 2003 at 11:19:48PM -0700, Ben Rudiak-Gould wrote:
> > On Fri, 1 Aug 2003, Glynn Clements wrote:
> > > Ben Rudiak-Gould wrote:
> > > >
> > > > A BlockRecoder takes source and destination buffers and does some
> > > > sort of translation between them...
> > > 
> > > It would be preferable if this wasn't all within the IO monad. It
> > > shouldn't be necessary, even for stateful encodings.
> > 
> > The problem is that all the Ptr access functions are in the IO monad...
> 
> this can all be done safely in the state monad (when using external c
> calls or not). I vaugly remember a binding to iconv floating around
> which was based on the state monad.  there was also an implementation
> (based on IO, but rather advanced) in the qforeign distribution which
> might be useful to look at.. (See Conv*.hs) 

Certainly the coder's internal state can be safely encapsulated in ST,
even if it contains Ptrs internally. The problem is the Ptrs passed to the
block-conversion function. Since they aren't parameterized by the state
variable, you have no idea where they've been. I suppose you could create
an STPtr type, but you'd have to impose such draconian restrictions on it
to ensure safety that it hardly seems worth it. (STPtrs couldn't be passed
to C code, for example.)

If an application wants to use these converters in an ST thread then it's
the application's responsibility to ensure safety, and so it should also
be the application's responsibility to use unsafeIOtoST.

I suspect that the iconv binding that you mentioned uses an ST-safe data
type like a list or an STUArray. I don't think that's efficient enough to
be used here (but I'd love to be proven wrong!).


-- Ben