You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@thrift.apache.org by Patrick Collison <pa...@collison.ie> on 2008/06/09 10:26:16 UTC

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

Re: Common Lisp port

Posted by Patrick Collison <pa...@collison.ie>.
On Mon, Jul 14, 2008 at 5:41 PM, David Reiss <dr...@facebook.com> wrote:
> You need to create a JIRA issue and attach the patch so that you can
> click the box that says you agree to have it distributed under the
> ASL.  After that, we can definitely merge it.

Done: https://issues.apache.org/jira/browse/THRIFT-82

Patrick

> --David
>
> Patrick Collison wrote:
>> Hey folks -- any chance of getting this merged?
>>
>> On Wed, Jun 11, 2008 at 12:51 AM, Patrick Collison <pa...@collison.ie>
>> wrote:
>>> On Mon, Jun 9, 2008 at 3:20 PM, Mark Slee <ms...@facebook.com> 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:patrick@collison.ie]
>>>> Sent: Monday, June 09, 2008 1:26 AM
>>>> To: thrift-user@incubator.apache.org
>>>> 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
>>>>
>>>
>>
>

Re: Common Lisp port

Posted by David Reiss <dr...@facebook.com>.
You need to create a JIRA issue and attach the patch so that you can
click the box that says you agree to have it distributed under the
ASL.  After that, we can definitely merge it.

--David

Patrick Collison wrote:
> Hey folks -- any chance of getting this merged?
> 
> On Wed, Jun 11, 2008 at 12:51 AM, Patrick Collison <pa...@collison.ie>
> wrote:
>> On Mon, Jun 9, 2008 at 3:20 PM, Mark Slee <ms...@facebook.com> 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:patrick@collison.ie]
>>> Sent: Monday, June 09, 2008 1:26 AM
>>> To: thrift-user@incubator.apache.org
>>> 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
>>>
>>
> 

Re: Common Lisp port

Posted by Patrick Collison <pa...@collison.ie>.
Hey folks -- any chance of getting this merged?

On Wed, Jun 11, 2008 at 12:51 AM, Patrick Collison <pa...@collison.ie> wrote:
> On Mon, Jun 9, 2008 at 3:20 PM, Mark Slee <ms...@facebook.com> 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:patrick@collison.ie]
>> Sent: Monday, June 09, 2008 1:26 AM
>> To: thrift-user@incubator.apache.org
>> 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
>>
>

Re: Common Lisp port

Posted by Patrick Collison <pa...@collison.ie>.
On Mon, Jun 9, 2008 at 3:20 PM, Mark Slee <ms...@facebook.com> 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:patrick@collison.ie]
> Sent: Monday, June 09, 2008 1:26 AM
> To: thrift-user@incubator.apache.org
> 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
>

RE: Common Lisp port

Posted by Mark Slee <ms...@facebook.com>.
I'm not sure the attachment made it through. (Was it a file or a link?
Maybe the Apache list doesn't like that...)

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:patrick@collison.ie] 
Sent: Monday, June 09, 2008 1:26 AM
To: thrift-user@incubator.apache.org
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