Logix: Adding macros to Python

Re:Logix: Adding macros to Python by pc on Tuesday September 11, 2007 @01:02AM (#53176)

"I was thinking myself that it would be pretty neat to write a Lisp dialect that compiled down to Python"

That would be an incredibly bad idea. The implementation of SBCL (and CMUCL, upon which SBCL is based) is second to none--it has an optimizing compiler (available at runtime) with code-generation backends for architectures from x86 to MIPS; fantastic support for type inference, inline expansion, modular arithmetic, unreachable code deletion, constant folding, control optimization, generational garbage collection (doesn't python still use reference counts?)... amongst a bunch of other stuff.

http://shootout.alioth.debian.org/gp4/benchmark.php?test=all...

Benchmarks are of course arbitrary, but no matter what way you dice things, SBCL is vastly superior to Python's crappy VM. In the case of the link above, over 10 times faster.

[ Parent | on HN ]

Re:Logix: Adding macros to Python by AF on Tuesday September 11, 2007 @01:09AM (#53178)

As I mentioned in another post, I'm aware of the qualities of SBCL. I know it is a much better VM. That's not what I am concerned about...what I like about Python is its quantity and consistency of libraries and its overall consistency period. Common Lisp just doesn't have that, and SBCL isn't perfect - its full functionality doesn't work across all platforms.

> That would be an incredibly bad idea.

And I'm just wondering...even with SBCL, why would it be an 'incredibly bad idea' to undertake such a project to convert a Lisp dialect to Python?

[ Parent | on HN ]

Re:Logix: Adding macros to Python by pc on Tuesday September 11, 2007 @01:32AM (#53187)

"I know it is a much better VM."

SBCL isn't a VM. It's a Lisp implementation with a compiler that generates native code.

Admittedly, many dynamic languages folks seem to find this concept odd. The idea that {dynamic typing, garbage collection, your favourite feature from ruby/python/perl/php} requires a VM unfortunately seems strongly ingrained.

[ Parent | on HN ]

[deleted]

Re:Logix: Adding macros to Python by pc on Tuesday September 11, 2007 @01:50AM (#53194)

Well, if you really want to use Lisp code and Python libraries, and are prepared to write a compiler, why not do the translation in the reverse direction? Write a compiler from Python to Lisp, and bring Python libraries to Lisp.

[edit: irrelevant stuff removed since parent was deleted]

[ Parent | on HN ]

Re:Logix: Adding macros to Python by AF on Tuesday September 11, 2007 @12:55PM (#53394)

It is definitely something to consider, and while I don't think translating Python to Common Lisp would be all that difficult, I do think that getting the C libraries that Python wraps working with CL might be a significant effort. A lot of the good libraries like csv, re, etc, are implemented in C if I remember correctly.

[ Parent | on HN ]

Re:Logix: Adding macros to Python by jey on Tuesday September 11, 2007 @01:18AM (#53184)

> And I'm just wondering...even with SBCL, why would it be an 'incredibly bad idea' to undertake such a project to convert a Lisp dialect to Python?

Well...what's the point of compiling Lisp into a language with a slower runtime? If you mean that you want it to compiel to something "pretty", well, the output of a compiler is generally not pretty. It's just meant to be used as opaque object code, not something for human consumption.

[ Parent | on HN ]

Re:Logix: Adding macros to Python by AF on Tuesday September 11, 2007 @01:39AM (#53191)

I thought I made it clear. The point of doing that is because you'd have simple access to Python's massive collection of quality libraries.

[ Parent | on HN ]

Re:Logix: Adding macros to Python by jey on Tuesday September 11, 2007 @01:59PM (#53442)

Oh, ok.

[ Parent | on HN ]

Re:Logix: Adding macros to Python by ced on Tuesday September 11, 2007 @04:23AM (#53220)

I "ported" my app from CLisp to SBCL and got a 4x performance decrease. Granted, I must create code at run-time, so CLisp's fast byte code generation probably ends up making the difference. Still.

[ Parent | on HN ]