david

Hi People,

I've just uploaded my updated version of the Lisp2Perl
translator/compiler - a generaly purpose program for 'compiling' lisp
programs (which look quite a bit like scheme programs) into efficient
perl code.

I've removed the 'include' system which tried to compile included files
if required and link everything up in the end (it didn't work very
well). Everything is much simpler and cleaner now. If you want
everything linked at the end (all the separate compiled lisp files) you
can do so easily enough ('cat' will do). This also gets rid of the
messiness of stripping macros since they are not needed at runtime -
nothing is stripped any more. It also now tracks lexical scopes so that
it can warn you of references to undefined variables (with
'(globals-check)'. It still needs work in this area.

I've been considering implementing a lisp2 version of it too - I started
(see misc/lisp2.scm in the tarball). It would probably make more sense.

http://www.hhdave.pwp.blueyonder.co.uk

ray dillinger

Okay, this will be handy for putting code into systems where
you can't count on a lisp environment being installed.

But... several common lisp compilers actually produce faster
executables than perl does. In fact, with appropriate
declarations, I think all of them do. If efficiency is your
goal, wouldn't it be more fruitful to translate perl into
lisp? (Maybe perl is faster now? I haven't looked at it
since Perl v4.)

Bear

david

I would imagine that many common lisp compilers do indeed produce faster
code than perl, but that wasn't what I meant when I said efficient perl
code - I meant efficient compared to other perl code. ie at least as
fast as perl code you would write by hand. I once implemented a purely
interprative lisp in perl. Hence: this compiler produces efficient code
(That interpreter was _seriously_ slow).

Also, I think translating perl into Lisp would be distinctly non trivial.

-- David