Proposal: add System.IO.hGetBufSome

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Proposal: add System.IO.hGetBufSome

Simon Marlow-7
http://hackage.haskell.org/trac/ghc/ticket/4046

I'd like to add the following function to `System.IO`, alongside
`hGetBuf` and `hGetBufNonBlocking`:

{{{
-- | 'hGetBufSome' @hdl buf count@ reads data from the handle @hdl@
-- into the buffer @buf@.  If there is any data available to read,
-- then 'hGetBufSome' returns it immediately; it only blocks if there
-- is no data to be read.
--
-- It returns the number of bytes actually read.  This may be zero if
-- EOF was reached before any data was read (or if @count@ is zero).
--
-- 'hGetBufSome' never raises an EOF exception, instead it returns a value
-- smaller than @count@.
--
-- If the handle is a pipe or socket, and the writing end
-- is closed, 'hGetBufSome' will behave as if EOF was reached.
--
-- 'hGetBufSome' ignores the prevailing 'TextEncoding' and 'NewlineMode'
-- on the 'Handle', and reads bytes directly.
}}}

We need it to properly fix #4041 and #3808.  It corresponds more closely
to the semantics of Unix `read()`, and I've found this to be the most
useful low-level API for reading in practice.

In the long term we'd like to provide a better binary I/O API, and we
might even get around to doing that before 6.14.1, but if not we'll need
this.

Deadline: 2 weeks.

Cheers,
        Simon
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: add System.IO.hGetBufSome

Jesper Louis Andersen-2
On Wed, May 5, 2010 at 12:18 PM, Simon Marlow <[hidden email]> wrote:
> http://hackage.haskell.org/trac/ghc/ticket/4046
>
> I'd like to add the following function to `System.IO`, alongside `hGetBuf`
> and `hGetBufNonBlocking`:

[...]

+1 from me. I would expect this to be available from System.IO as it
closely resembles the low-level UNIX call. The BSD socket API is
definitely one of the better out there, if you squint the eyes and
look through the haze of C.q


--
J.
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: add System.IO.hGetBufSome

Malcolm Wallace
>> http://hackage.haskell.org/trac/ghc/ticket/4046

+1 from me too.

Regards,
     Malcolm

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: add System.IO.hGetBufSome

Thomas Schilling-2
In reply to this post by Simon Marlow-7
+1 from me as well

On 5 May 2010 11:18, Simon Marlow <[hidden email]> wrote:

> http://hackage.haskell.org/trac/ghc/ticket/4046
>
> I'd like to add the following function to `System.IO`, alongside `hGetBuf`
> and `hGetBufNonBlocking`:
>
> {{{
> -- | 'hGetBufSome' @hdl buf count@ reads data from the handle @hdl@
> -- into the buffer @buf@.  If there is any data available to read,
> -- then 'hGetBufSome' returns it immediately; it only blocks if there
> -- is no data to be read.
> --
> -- It returns the number of bytes actually read.  This may be zero if
> -- EOF was reached before any data was read (or if @count@ is zero).
> --
> -- 'hGetBufSome' never raises an EOF exception, instead it returns a value
> -- smaller than @count@.
> --
> -- If the handle is a pipe or socket, and the writing end
> -- is closed, 'hGetBufSome' will behave as if EOF was reached.
> --
> -- 'hGetBufSome' ignores the prevailing 'TextEncoding' and 'NewlineMode'
> -- on the 'Handle', and reads bytes directly.
> }}}
>
> We need it to properly fix #4041 and #3808.  It corresponds more closely to
> the semantics of Unix `read()`, and I've found this to be the most useful
> low-level API for reading in practice.
>
> In the long term we'd like to provide a better binary I/O API, and we might
> even get around to doing that before 6.14.1, but if not we'll need this.
>
> Deadline: 2 weeks.
>
> Cheers,
>        Simon
> _______________________________________________
> Libraries mailing list
> [hidden email]
> http://www.haskell.org/mailman/listinfo/libraries
>



--
Push the envelope.  Watch it bend.
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries