ByteString-backed Handles, and another couple of questions
Bryan O'Sullivan
bos at serpentine.com
Tue Dec 15 15:48:56 EST 2009
On Tue, Dec 15, 2009 at 1:39 AM, Simon Marlow <marlowsd at gmail.com> wrote:
>
> I haven't implemented a bytestring-backed Handle, but as you say all the
> abstractions should be present. It would be a great thing to have on
> Hackage.
>
> A good starting point would be the mmap-backed Handle code that I wrote for
> my talk at the Haskell Implementors Workshop last year. I'd intended to
> polish this up and upload to Hackage, but never got around to it. I've put
> the code here for now:
>
> http://www.haskell.org/~simonmar/mmap-handle.tar.gz
Ooh, thanks! I'll take a look-see.
> Yes, you may remember we talked about this in Edinburgh (the conversion
> would probably make more sense to you now than it did then :-).
>
I do indeed remember :-)
One thing I experimented with is making CharBuffers use UTF-16. You'll see
> some instances of #ifdef CHARBUF_UTF16 in the code - it partially works, I
> believe the main missing piece is support in the built-in codecs. I don't
> think it would be too hard to fix them, they just need to more abstract
> about offsets in the CharBuffer; writeCharBuffer/readCharBuffer already
> handle the UTF-16 encoding/decoding.
>
> So one possibility is to get this working and then avoid the extra copy by
> just taking out the ByteArray# inside a CharBuffer and turning it into a
> text buffer. I'm not sure of the details here, but I imagine something along
> those lines would work. We would then have to allocate a new CharBuffer for
> the Handle.
>
Yes, that would amount to double-buffering, and would work nicely, only the
current buffers go through foreign pointers while text uses an unpinned
array. I can see why this is (so iconv can actually work), but it does
introduce a fly into the ointment :-)
> Another possibility is (as you suggested) to make Handles independent of
> the representation of the CharBuffer, making it completely abstract. I
> haven't put much thought into that, it might well be a better approach. It
> would presumably involve a new existential class constraint in the Handle
> for the CharBuffer operations, and we'd have to be careful about
> performance: currently I think the CharBuffer operations get inlined nicely.
>
Aye. I think this would have the same problem with foreign transcoding code
that wants a reliable pointer.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20091215/833db00d/attachment-0001.html
More information about the Glasgow-haskell-users
mailing list