Moving off list to the Wiki has my vote. On Mon, Jun 22, 2009 at 7:52 AM, Thomas DuBuisson<thomas.dubuis...@gmail.com> wrote: > Johan - glad you chimed in! > > I'm all in favor of keeping a low level interface and don't have an > issue with Network.Socket existing, I additionally really like the > suggestion of moving from the ML to a wiki in the same style as > Haskell'. > > I'll port these comments to the wiki if that is whats agreed on and > hold off on other thoughts for now. > > * ByteStrings! Absolutely. The one issue is I feel network packets > should be represented as strict bytestrings and any encode/decode > issues resulting in a 'Left err' via binary-strict or some beefed up > version of that package. > > * Avoiding a 'heavy weight' solution for socket state might get ugly > fast with all the 'Either a b' results that we'll need - also a socket > can close at any time so a socket in 'Connected' state might not > actually be connected. I understand the attraction to a light > solution using existential types but Tim Sheard sketched for me a > reasonable alternative which I invite him to restate here, if he has > the time. > > Thomas > > On Mon, Jun 22, 2009 at 12:16 AM, Johan Tibell<johan.tib...@gmail.com> wrote: >> On Mon, Jun 22, 2009 at 1:22 AM, Thomas DuBuisson >> <thomas.dubuis...@gmail.com> wrote: >>> >>> I'm in favor of the entire Network library being reworked with an >>> improved API that is higher level and type-safe instead of a direct >>> translation/FFI of Berkeley sockets. I also would like the Network >>> package to export Data instances for headers while taking advantage of >>> pretty, prettyclass, and parsec. I started such work with >>> network-data but never really got off the ground with it. >> >> I've given this some thought. There are a few different things that would be >> nice to have in a new API: >> >> * Use a binary type (e.g. ByteString) instead of Strings. (see >> network-bytestring) >> * Encoding more things in the type system, in particular the socket state >> (opened, closed, connected, etc). I would like to avoid a very heavyweight >> encoding though. >> * Allow folds over the input i.e. foldSocket :: (a -> ByteString -> a) -> a >> -> Socket -> IO a >> >> I'm all for having a higher level API but I would like to keep the Berkeley >> socket interface. The reason is the following: If we provide a higher level >> API that does not expose the whole underlying OS API there will be some >> users who can't use the library and will have to resort to writing their own >> bindings. I've seen this problem in a few other libraries. The reasoning >> often goes something like this: This interface will cover 90% (or 95%) of >> all the use cases so its sufficient for most people. The problem with this >> kind of reasoning is that I have to write my own OS bindings for every ten >> libraries I use (on average). >> >> Perhaps we should start a wiki page where we can take some notes on things >> that could be improved in the style of Haskell' discussions (i.e. outlines >> of the problem together possible solutions together with their trade-offs. >> Python's PEPs are a good model here)? >> >> -- Johan >> >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe@haskell.org >> http://www.haskell.org/mailman/listinfo/haskell-cafe >> >> > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe >
-- /jve _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe