Re: [web-devel] Proposal: http-types

Am 02.02.2011 22:34, schrieb Aristid Breitkreuz:

This is not a problem because constructing OtherMethod "POST" is forbidden and will/must never happen. byteStringToMethod will always construct POST, and not OtherMethod "POST",

Similar discussions come up again and again. http://hackage.haskell.org/packages/archive/HTTP/4000.1.1/doc/html/Network-H... even contains a comment "Encoding HTTP header names differently, as Strings perhaps, is an equally fine choice..no decidedly clear winner" Network.HTTP.Base.RequestMethod is a similar data type. My own conclusion is: avoid as many variants as possible, otherwise you'll get lots of repetitions of similar code. A single variant wrapping a String or ByteString is the best for uniform treatment (i.e. just for implementing show). You loose (possibly faster and shorter) pattern matching, but I think it is just as good to use predefined constants and "==" for comparisons. Cheers Christian

2011/2/2 Michael Snoyman mailto:michael@snoyman.com>

Originally WAI *did* use an ADT. However, someone (I *think* Jeremy Shaw, I'm not sure) pointed out that pattern matching is in fact broken here:

case OtherMethod POST of POST -> putStrLn "Will not get called"

Also, with your implementation

POST /= OtherMethod "POST"

Michael

On Wed, Feb 2, 2011 at 11:12 PM, Aristid Breitkreuz mailto:aristidb@googlemail.com> wrote: > You essentially forced me to do this. ;-) > So here it is, my initial version of > http-types: https://github.com/aristidb/http-types > Only Method is supported for now. > I deliberately chose to make it an ADT for type safety reasons. This is to > enable developers to write case x of POST -> ..., and the compiler will find > if they accidentally typed POSTX. However, non-standard methods are also > supported via OtherMethod. > Please take it apart and criticize! :-) > If you have implementation ideas, just fork it, or I can add you as a > contributor. > > Aristid > > 2011/2/2 Michael Snoyman mailto:michael-cq0OxgmGHj5BDgjK7y7TUQ@public.gmane.org> >> >> I think there's general consensus that this package would be a Good >> Thing(tm), and at the least you'll have my support on it. I'm sure we >> can all quibble on details later, but I think the best thing now would >> be to have some actual code to look at. >> >> Aristid, I'm assuming (hoping) you were volunteering to actually write >> and maintain this package, is that correct? I would recommend you get >> a project started (Github, BitBucket, PatchTag, wherever), getting up >> some code and then we can all nit-pick it to death ;). >> >> Michael >> >> On Wed, Feb 2, 2011 at 3:45 PM, Aristid Breitkreuz >> mailto:aristidb-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> wrote: >> > http-enumerator could at least for compatibility support a Request type >> > with >> > ByteString. And also a native request type. Or something along these >> > lines. >> > The problem is that I want to be able to use a Request type that is >> > compatible between multiple client libraries, enabling me to >> > theoretically >> > switch implementations without a huge amount of hassle. >> > >> > Aristid >> > >> > 2011/2/2 Michael Snoyman mailto:michael@snoyman.com> >> >> >> >> On Wed, Feb 2, 2011 at 2:50 PM, Aristid Breitkreuz >> >> mailto:aristidb-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org> wrote: >> >> > I agree with most things. >> >> > >> >> > 2011/2/2 Michael Snoyman mailto:michael-cq0OxgmGHj5BDgjK7y7TUQ@public.gmane.org> >> >> >> >> >> >> * Request and response datatypes themselves. I don't think this >> >> >> makes >> >> >> sense to put in http-types: just between WAI and http-enumerator I >> >> >> needed different versions of these. >> >> > >> >> > I think this is where we could derive most value, and it would be >> >> > good >> >> > to >> >> > find a way to do it. >> >> > Request actually looks pretty similar in WAI as in http-enumerator, >> >> > but >> >> > Response is different. Maybe distinguish between client and server >> >> > versions >> >> > of Response? >> >> >> >> I'd be very surprised if those two can be meaningfully unified. What >> >> do you do about remoteHost and errorHandler? Also, it's more useful to >> >> have the request body for http-enumerator be an Enumerator of >> >> Builders, as opposed to WAI where we want an Enumerator of >> >> ByteStrings. >> >> >> >> I have no opposition to *having* a Request type in http-types (or >> >> whatever we call it), but I doubt anyone will actually use it, and I >> >> wouldn't even want it to include Builder due to the extra dependency. >> >> >> >> Michael >> > >> > > >

_______________________________________________ web-devel mailing list web-devel-HC+Z4NTRIlBAfugRpC6u6w@public.gmane.org http://www.haskell.org/mailman/listinfo/web-devel