[racket] wffi (a "literate" web service "FFI" using a markdown file with parameterized HTTP messages)

To follow up, I just pushed a PLaneT package for the Google API
Discovery service, which means ~40 Google web services including
things like goo.gl, Google+, and so on.

GitHub: https://github.com/greghendershott/gapi
PLaneT: http://planet.racket-lang.org/display.ss?package=gapi.plt&owner=gh

Disclaimer: If PLaneT allowed 0.x version numbers, I'd put this around
0.8. Welcome any feedback or bugs reports.

At Sunday's hacketathon, Eli showed me how to pull off creating the
function wrappers at compile-time using macros. I can't thank him
enough for squeezing my brain through macro crucible, even if it took
a good night's sleep for me to put the pieces back together again.

What I'd like to do next is loop back to my original idea of a very
simple markdown format file where documentation=specification. The
Google API discovery document JSON format is quite flexible. But it is
both too simple and too complicated. On the one hand it can't quite
handle some header- and signature-heavy services like some of
Amazon's. And on the other hand it's really overkill for many simple
web services like imgur or last.fm. You certainly wouldn't want to
write that format by hand. Anyway, now I know how to create function
wrappers at compile-time for that markdown format, using what I just
learned.

On Thu, Oct 11, 2012 at 6:13 PM, Eli Barzilay <eli at barzilay.org> wrote:
> Two days ago, Greg Hendershott wrote:
>> 2. A markdown -> API JSON format tool, to make quick work of other
>>    web services.
>
> In the Racket context this should be almost trivial, since you don't
> need markdown -- just have text with @scribble things that have the
> json stuff as-is instead of parsing text.
>
>
> Two days ago, Greg Hendershott wrote:
>>
>> 2. Part of me is starting to suspect seduction by the sirens of
>> runtime dynamism and macros. Instead, maybe real users want a
>> library that works, don't care how, but do want good docs and
>> checks. Instead of a runtime/macro proposition, a tool could emit a
>> literal .rkt file, plus maybe some head-start markdown and/or
>> Scribble docs. To which a package developer would apply some spit
>> and polish, and push to PLaneT and/or GitHub.
>>
>> Re this second approach, note that the Google JSON API format
>> appears to have enough info to generate contracts for untyped
>> Racket, as well as Typed Racket interfaces.
>>
>> I'm not sure if I'm explaining the choice clearly, but, any feelings
>> or suggestions about this?
>
> I'm not sure about the details, but usually it's fine to start with
> something "very dynamic" that can even go as far as using `eval' to
> generate code -- and then you have enough code to "shift things up"
> and do the work at the macro level instead, producing code rather than
> strings/sexpr/etc.  (But IMO it's necessary to do the switch for a
> proper library, so the danger of doing this is giving up half-way and
> staying with the dynamic hacks.)
>
> --
>           ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
>                     http://barzilay.org/                   Maze is Life!