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