Hey folks -- any chance of getting this merged?
On Wed, Jun 11, 2008 at 12:51 AM, Patrick Collison <[EMAIL PROTECTED]> wrote: > 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 >> >
