Thanks Brandon, forgot to send my reply to the list: Ok, so I am confusing things. Good to know. So my question is how do I fulfill this scenario? - I have an action that might return either an HttpResponse or an HttpRequest, depending on if the IO in the action determined more work needed doing. It's here, though I doubt it's "correct" yet: requestHandler :: HttpRequest -> IO HttpResponse requestHandler request = do session <- sessionHandler request ret <- uriHandler request case ret of HttpResponse -> ret HttpRequest -> resourceHandler session ret uriHandler :: HttpRequest -> IO HttpMessage sessionHandler :: HttpRequest -> IO HttpSession I've given the uriHandler a signature of IO HttpMessage because the HttpMessage might be either an HttpResponse or an HttpRequest, and I don't know how I should be specifying that. Ideas? - Stephen Brandon S. Allbery KF8NH wrote:

On Jun 18, 2008, at 15:31 , Stephen Howard wrote:

...

HttpMessage.hs:36:20: Not in scope: type constructor or class `HttpRequest'

The troublesome line is the definition of the cookie function at the end of the code. I've made

Right. "HttpRequest" is a data constructor associated with the type constructor "HttpMessage". (Data constructors are effectively functions; you used it in the context of a type, not a function name.)

Cool, "Either" looks like what I'm looking for. I'll have to look into that. What do I do about the fact that both HttpRequest and HttpResponse have some of the same named fields (headers and body, for example). Seems a pain to drop them into separate modules just so I can keep the naming conventions consistent. - Stephen Ryan Ingram wrote:

It sounds like you need to split up your types a bit more.

data HttpRequest = HttpRequest ...

data HttpResponse = HttpResponse ...

data HttpMessage = MsgRequest HttpRequest | MsgResponse HttpResponse -- alternatively -- type HttpMessage = Either HttpRequest HttpResponse

Now you can have functions that take/return just an HttpRequest or just an HttpResponse, as well as functions that use either one via HttpMessage. In the latter case, you do need to pattern match to decide which one you have.

-- ryan

On 6/18/08, Stephen Howard wrote:

...

Thanks Brandon, forgot to send my reply to the list:

Ok, so I am confusing things. Good to know. So my question is how do I fulfill this scenario?

- I have an action that might return either an HttpResponse or an HttpRequest, depending on if the IO in the action determined more work needed doing. It's here, though I doubt it's "correct" yet:

requestHandler :: HttpRequest -> IO HttpResponse requestHandler request = do session <- sessionHandler request ret <- uriHandler request case ret of HttpResponse -> ret HttpRequest -> resourceHandler session ret

uriHandler :: HttpRequest -> IO HttpMessage sessionHandler :: HttpRequest -> IO HttpSession

I've given the uriHandler a signature of IO HttpMessage because the HttpMessage might be either an HttpResponse or an HttpRequest, and I don't know how I should be specifying that. Ideas?

- Stephen

Brandon S. Allbery KF8NH wrote:

...

On Jun 18, 2008, at 15:31 , Stephen Howard wrote:

...

HttpMessage.hs:36:20: Not in scope: type constructor or class

`HttpRequest'

...

...

The troublesome line is the definition of the cookie function at the end

of the code. I've made

...

Right. "HttpRequest" is a data constructor associated with the type

constructor "HttpMessage".

...

(Data constructors are effectively functions; you used it in the context

of a type, not a function name.)

...

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

If it helps, feel free to use a different name for the data constructors and their data type until the difference is painfully clear to you (maybe suffix the constructor with a C or prefix by Mk). Data types and constructors live in different namespaces and can happily use the same identifier. That doesn't mean you have to, if it means more work deciphering error messages. Computers would be just as happy with identifiers like g2ch_Sw'K54h (just take a look at the GHC simple core dump!), so pick ones that you yourself find perspicuous. Dan Ryan Ingram wrote:

It sounds like you need to split up your types a bit more.

data HttpRequest = HttpRequest ...

data HttpResponse = HttpResponse ...

data HttpMessage = MsgRequest HttpRequest | MsgResponse HttpResponse -- alternatively -- type HttpMessage = Either HttpRequest HttpResponse

Now you can have functions that take/return just an HttpRequest or just an HttpResponse, as well as functions that use either one via HttpMessage. In the latter case, you do need to pattern match to decide which one you have.

-- ryan

On 6/18/08, Stephen Howard wrote:

...

Thanks Brandon, forgot to send my reply to the list:

Ok, so I am confusing things. Good to know. So my question is how do I fulfill this scenario?

- I have an action that might return either an HttpResponse or an HttpRequest, depending on if the IO in the action determined more work needed doing. It's here, though I doubt it's "correct" yet:

requestHandler :: HttpRequest -> IO HttpResponse requestHandler request = do session <- sessionHandler request ret <- uriHandler request case ret of HttpResponse -> ret HttpRequest -> resourceHandler session ret

uriHandler :: HttpRequest -> IO HttpMessage sessionHandler :: HttpRequest -> IO HttpSession

I've given the uriHandler a signature of IO HttpMessage because the HttpMessage might be either an HttpResponse or an HttpRequest, and I don't know how I should be specifying that. Ideas?

- Stephen

Brandon S. Allbery KF8NH wrote:

...

On Jun 18, 2008, at 15:31 , Stephen Howard wrote:

...

HttpMessage.hs:36:20: Not in scope: type constructor or class `HttpRequest' The troublesome line is the definition of the cookie function at the end of the code. I've made Right. "HttpRequest" is a data constructor associated with the type constructor "HttpMessage". (Data constructors are effectively functions; you used it in the context of a type, not a function name.)

_______________________________________________ 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