Proposal #2998: Expose the internals of the network library to
make it more extensible
dons at galois.com
Sun Feb 1 18:24:10 EST 2009
Let's do it. The FFI layer should in general be exposed imo, via some
> Hi all,
> In short, I propose that we export some of the internals of the
> network library in a new module to make it easier to write portable
> libraries on top of the library. I've added the full proposal, copied
> from Trac, below. The motivating example is network-bytestring which
> needs to marshall different socket related data types to support e.g.
> Discussion deadline: 2 weeks (non disruptive change)
> When creating new libraries on top of the network library it would be
> convenient if the library exposed some functions that hide platform
> variations so that the new libraries can be written in a portable
> Take for example the currently un-exported pokeSockAddr function which
> marshalls a SockAddr into a sockaddr struct. This function would be
> useful when e.g. writing a binding for the sendmsg system call.
> However, it's not exported so libraries are forced to define their own
> This is unfortunate. I propose we add a new module,
> Network.Socket.Internal, to the network library, that exposes these
> portable marshalling functions. It might also be a good idea to expose
> some internal data representations in the same way bytestring
> currently does. People who write code that uses this internal do so
> knowing that there is a risk that the interface and data
> representations might change.
> I've written a patch that exposes some of the library's internal
> functions. There are still some documentation to write and perhaps a
> few more functions to expose but I think we should reach consensus on
> whether this is a good idea to begin with before continuing.
> Since this change isn't disruptive I propose a two week consideration deadline.
> Cabal package:
> Libraries mailing list
> Libraries at haskell.org
More information about the Libraries