buildRequest is in IO and requires an open connection about http-streams HOT 9 CLOSED

The current design is because right now Request has a Host: header filled in when buildRequest runs, resulting in a Request [headers] object that is fully complete. I suppose there's no absolute reason that this has to be the case; the Host: field is admittedly special and the only time you'll see it before sending is debugging calling show. It seems unfaithful to the person debugging to show them the object without one of the headers that will be sent.

@gregorycollins could I get your opinion of this? I'm all for greater purity, but I also like it the way it is. Of course I do :)

AfC

from http-streams.

We override things in snap all the time if the protocol demands it, I think
having RequestBuilder be self contained might be better. I can see your
argument though.
On Mar 6, 2013 10:38 PM, "Andrew Cowie" [email protected] wrote:

The current design is because right now Request has a Host: header filled
in when buildRequest runs, resulting in a Request [headers] object that is
fully complete. I suppose there's no absolute reason that this has to be
the case; the Host: field is admittedly special and the only time you'll
see it before sending is debugging calling show. It seems unfaithful to
the person debugging to show them the object without one of the headers
that will be sent.

@gregorycollins https://github.com/gregorycollins could I get your
opinion of this? I'm all for greater purity, but I also like it the way it
is. Of course I do :)

AfC

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/9#issuecomment-14527749
.

from http-streams.

So I've remembered one more reason I designed it the way I did. As a once-upon-a-time Haskell newbie, I hated the asymmetry that within a do block, some of the lines are

a <- action

and others are

let b = func

even though I can parse that now, it still drives me bananas. Then someone suggested to me that I could, if I really wanted, just do

a <- action
b <- return $ func

and that the compiler would rapidly optimize it away. Now, as for http-streams, I aesthetically feel that

c <- openConnection "server.example.com" 80
q <- buildRequest c $ do ...
a <- sendRequest ...
b <- receiveResponse ...

looks a lot better than

c <- openConnection "server.example.com" 80
let q = buildRequest c $ do ...
a <- sendRequest ...
b <- receiveResponse ...

[a and b are admittedly optional; depends what you're doing with α and β].

Anyway, I'm willing to try a patch doing away with the Connection parameter, but while I'm testing I'll be leaving it in IO just to reduce the momentarily breakage, and that reminded me of this design matter.

AfC

from http-streams.

With all due respect, I beleive restricting a function to IO just because the "v <- action" syntax looks better to your eyes than "let v = function" is wrong.

buildRequest sould be exposed pure (let's call that "makeRequest"), and if you really prefer the bind syntax rather that the let syntax, use return (or pure, or unit ...) on site.

Also, tibbe suggested using record syntax to set the parameters of the request. I think this is even more straightforward than the monoid instance.

from http-streams.

Also, tibbe suggested using record syntax to set the parameters of the request. I think this is even more straightforward than the monoid instance.

...until people rely on the fact that you've exposed your record constructors and fields to construct objects by themselves, and you can't add fields to your record without breaking user code.

from http-streams.

@paul-r-ml Of course. I merely pointed out one of the reasons I did it the way I did. It was one of the hardest things to understand my first months working in Haskell; I think it's an enormous syntax wart in the language and I'm glad Ben Lippmeier has made the "let" optional in his Disciple language. Anyway.

@gregorycollins Bang on. Watching the conduits people struggle with that issue made me vary wary of exposing records; In my other projects I have worked very hard to use e.g. a language's visibility mechanisms to keep internals internal.

I'm working on a patch to make buildRequest pure. That'll bump us to 0.4.0, I believe.

AfC

from http-streams.

@gregorycollins indeed, this might get problematic. How about just exposing fields, but not the constructor (instead, provide a defaultRequest function) ? Is that technically doable ? Would that solve the issue ?

@afcowie thank you for working on that

from http-streams.

@paul-r-ml you can export get/set functions, but they're not intrinsically better in "Request -> Request" style than they are in state monad style, especially when some of these functions need to do IO.

from http-streams.

People keep asking for buildRequest to be pure. Have decided to do so. Will bump API to 0.8.

from http-streams.