thrift-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Patrick Collison" <>
Subject Re: Common Lisp port
Date Wed, 11 Jun 2008 07:51:40 GMT
On Mon, Jun 9, 2008 at 3:20 PM, Mark Slee <> 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



> 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 []
> Sent: Monday, June 09, 2008 1:26 AM
> To:
> 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
>, 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

View raw message