On Mon, Jun 9, 2008 at 3:20 PM, Mark Slee <[EMAIL PROTECTED]> wrote: > I'm not sure the attachment made it through. (Was it a file or a link? > Maybe the Apache list doesn't like that...)
Hmm, seems like it didn't. It's now at http://collison.ie/code/thrift-cl.patch. Cheers, Patrick > Sounds like a cool implementation, and I don't think it violates the > spirit of Thrift since this sounds like a somewhat natural thing to do > in the Lisp world for compatibility. > > -----Original Message----- > From: Patrick Collison [mailto:[EMAIL PROTECTED] > Sent: Monday, June 09, 2008 1:26 AM > To: [EMAIL PROTECTED] > Subject: Common Lisp port > > Hey, > > Attached is a port to Common Lisp. > > It's fairly rough, but since it's now good enough for my uses, I'm > releasing it in case I never get around to cleaning it up fully. > > Some implementation notes: > - It supports both client and server use. > - It depends on Allegro Common Lisp for reading and writing floats (CL > has no portable way of doing this), but adding support here for other > implementations will be trivial. > - It requires ASDF (a Common Lisp packaging system), and depends on the > usocket and trivial-utf-8 libraries. > - The generator works by translating the Thrift IDL to s-expressions > (you can see tutorial.thrift's form at > http://collison.ie/code/thrift-tutorial.lisp), and then doing the actual > compilation in Lisp. Though this compilation will happen every time the > source file is loaded, it's very fast: using Allegro, it takes me around > 10 msec total to compile shared.thrift and tutorial.thrift. Doing the > compilation at load-time is arguably against the spirit of Thrift, but > in practice this approach works quite nicely with CL. Since source-files > are only loaded once per session (which, in deployed systems, tend to > run for days/months), the overhead is negligible, and greatly outweighed > by the advantages (simpler code, more compile-time optimisation). It's > worth pointing out that the load-time compilation is also completely > transparent to the user, and the code generated by the C++ compiler can > be loaded as if it were ordinary Lisp code (indeed, thanks to macros, it > is). > - There's actually another big reason for the intermediate s-exp > approach -- it means ports to Scheme/Arc/Your Favourite Lisp Dialect can > be done without any new C++ generator code. > - It's the smallest port by a fairly large margin -- 892 non-blank lines > total (325 lines of C++, 567 lines of CL). By contrast, Haskell > (say) is 1730 (1285 C++, 445 Haskell), and Ruby is 1845 (848 C++, 997 > Ruby). > > Feedback and improvements are of course welcome. > > Cheers, > > Patrick >
