Re: [web-devel] web-routes-quasi

On 12 April 2010 17:02, Michael Snoyman wrote:

On Mon, Apr 12, 2010 at 1:17 AM, Peter Robinson wrote:

...

On 11 April 2010 07:00, Michael Snoyman wrote:

...

...

- Wouldn't it be simpler to automatically derive an instance of Show for the MyRoute type? (Since MyRoute is created on the fly anyway, I don't see why anyone would want to derive a different Show instance.)

Multiple problems: * The rest of web-routes doesn't use Show that way. * Usually, we'll need another parameter to create this function, such as the application root. * Show is usually the inverse of Read. I suppose we could make the Read instance the other side, but that we're just not following what is normally expected of these instances, which is to return Haskell-formatted data.

Right. I've noticed that your newest approach uses an "explode" function which makes the type signature of handler functions shorter. :)

Wow, I can't believe anyone was able to follow that code ;). My hat's off to you.

Well, using -ddump-splices it turned out to be an educative experience as it helped me to understand template haskell and quasi-quoting. The current implementation in GHC seems to be quite different from the one described in the original papers, so reading your code helped me fill in the blanks! :)

Someone (maybe you) mentioned earlier that web-routes-quasi is geared more towards framework writers; I think this is probably very true.

It wasn't me, but I do agree. ;) Nevertheless, I think web-routes-quasi together with a templating package will facilitate writing small web apps a lot.

Nonetheless, before release I'll put in proper documentation about the type signatures of all the parameters, since the whole thing can be very tricky. I myself had trouble figuring it out for integration into Yesod, and I wrote all the packages involved!

...

...

...

- About the possibility of querying the supported methods: The use case scenario I have in mind is having a default handler for handling OPTIONS that returns the available methods. Currently this won't work since that part of the resource information is unavailable inside the handler. Do you have any thoughts on how to change the design to make this possible?

Well, the simplest thing I can do is make the [Resource] result from the quasi-quoting available, which would give you enough information to write something to intercept OPTIONS requests before handing them to the rest of the application. Does that sound good enough?

Yes, sounds good. (Alternatively, I could separate parseRoutes from createRoutes and make the resources a top level declaration, which wouldn't require any changes on your part...)

Actually, that sounds like a much better idea. I'm trying to ensure that web-routes-quasi generated code compiles without warnings on -Wall, and exporting information that won't be used normally would generate an unused warning.

Ok, then let's leave it that way. Peter