[web-devel] web-routes-quasi

[Peter Robinson]

On 12 April 2010 17:02, Michael Snoyman <michael at snoyman.com> wrote:
> On Mon, Apr 12, 2010 at 1:17 AM, Peter Robinson <thaldyron at gmail.com> wrote:
>> On 11 April 2010 07:00, Michael Snoyman <michael at snoyman.com> 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