thrift-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Patrick Collison" <>
Subject Common Lisp port
Date Mon, 09 Jun 2008 08:26:16 GMT

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

Feedback and improvements are of course welcome.



  • Unnamed multipart/mixed (inline, None, 0 bytes)
View raw message