First I have to say that I really respect the result you have got and the effort you have spent. It obviously helped your project, and might help others.

I realize Perl's power in certain AI application areas, especailly those areas that heavily reply on a language's ability to process "symbolic language", and Perl's strong regexp support can really help, at least certain portion of such an AI application.

But in general, I am very suspicious about programming language conversion. Especially from a language that has specially targetted application area, to a general language like Perl. The need or motivation of such coversion, most likely, indicates that the choice of Lisp was wrong at the beginning.

It is not a surprise to see that Lisp and Perl have common components and functionalities between them, but who not? To be able to convert a program, line by line, from one language to another, is probably not difficult, but I don't think anybody can straightly summarize and generalize the wisdom and skill of using the target language (in this case, Perl).

Although Perl can be used for almost everything, AI was never the targeted area for Perl, but AI is one of the main targeted area for Lisp.

It sure did help my project. I see your point about programming language conversion. I'd be suspicious of it too. It's generally a pretty hard thing to do due to fundamental differences in programming languages. I'd hate, for example, to try and convert perl or lisp into VB - lack of lexical closures would just be too crippling.

I didn't think at one time that it would be possible to do justice to a lisp->perl conversion either.

As I've said on my website, the main use I've put this to (apart from compiling itself) is in converting XML from one form to another, whilst validating it at the same time. I wrote the previous version of this program in perl and it worked pretty well. The code was reasonably nice. I always had a feeling, though, that there must be a much easier way of doing it. What I almost wanted was a special purpose 'conversion language', but with the power of a general purpose language. (XSLT would not nearly have done).

I don't see lisp as a non general purpose language, though I realise it was originally intended/used for AI. I think it makes an excellent general language (though perl has its advantages - otherwise I wouldn't use it). I don't think that <it>it</it> was the wrong choice of language. Perl was. It wouldn't have been unreasonable to implement the whole thing in lisp. The lisp code base for this translator is MUCH cleaner, more complete and nicer to work with than the perl one, despite the general strangeness of translating it to perl. Its also faster!

There is one feature of lisp (this one included) which made it worth doing this project in lisp, and that is macros. Macros are _enourmously_ powerful. If you haven't ever used them I'd strongly recommend you look into them. Going from a language w/o macros to one with is like going from a line number version of BASIC to perl (almost/sort of). Paul Graham has written a lot about this (www.paulgraham.com).

Of course, perl 6 is going to implement macros, which will be very cool.

I have not yet had the time to investigate source filters to my liking (its on my list), but it seems like you have the full power of Perl available to you at compile time to munge the code in any way you see fit. Could some one give me the 50,000 ft overview of why Lisp macros are easier/stronger/faster/better? Is it a matter of syntatic sugar, or is there a deeper principle involved. (OK, my initial guess is that you'd have to include a full perl parser in your source filter to have a truly flexible macro system.)

Especially from a language that has specially targetted application area, to a general language like Perl. The need or motivation of such coversion, most likely, indicates that the choice of Lisp was wrong at the beginning.

I know many Lisp developers (myself included) who would disagree that it's aimed at a particular application area. It's like saying Perl is only useful for CGI scripts. While Lisp was certainly used a lot for AI work, it wasn't targeted at the AI field - it just happened to be the language best suited to it at the time.

I can't get to your website, so it's hard to say, but it could be interesting. Especially if one could use it to write Lisp but leverage the power of CPAN, for example. Being a Common Lisp person myself I can't especially say that I care for it being Schemish, but it's your baby. :-)

Thanks to others for correcting my URL.

Being able to leverage the power of CPAN was one of my reasons for doing it (though I've only just implemented a way of calling perl methods). Plus things like perls great regex support. Since I've started playing with Lisp I've decided I really like it. In particular I think macros are fantastic. It implements common lisp like (defmacro ...). In fact, that is how most of it is implemented.

If you want it to be more common lisp like (2 namespace, and other stuff) you can easily achieve that by redefining (and adding to) some of the core macros. There's a macro (*FCALL*) which is expanded to do ordinary function calls. If you wanted to help trying to get it to be more compatible with common lisp (maybe as a 'compiler personality' or something) that would be cool

Glad it interests you. I really ought to spend more time learning common lisp myself.

I guess I'll release it under the same license terms as perl itself (GPL/Artistic).

It does include a top level REPL - just download, unpack the tarball and type perl rep.scm.pl. I've been using that a lot myself. I run it from within emacs in an inferior scheme buffer so that I can edit lisp function defs and forms and evaluate them straight away. It's a great way to develop code interactively. I wish I could do it like that for perl.