Looking for a LISP -> C (or PDL) translator

[Niels Mayer]

In article <10064 at zodiac.ADS.COM> jtn at zodiac.ADS.COM (John Nelson) writes:
>Hi.  Does anyone know of any Common LISP or Franz LISP -> C or PDL
>translator programs out there?  I'm converting some LISP code into C
>and I'd like an automatic tool that helps me do this accuratly.

I too would love to see a COMMON-LISP to STANDALONE C translator for use
with XLISP in WINTERP (see prev post about lisp and x). I'd be particularly
interested in translators that "localize" memory management and pick an
optimum strategy for memory management based on object-useage and object
longevity. Other nice optimizations would be the ability to translate
data-dependent computations into CASE statements, optimized IF-THEN-ELSE
statements, hash table lookups, etc.

I get the feeling that these are higher-level optimizations that
traditional Lisp compilers don't deal with.  The "problem" is that lisp
lets you design with higher level abstractions that may be inefficient in
implementation; this of course isn't a problem for prototyping code, only
delivery. C programmers can't take advantage of the forced abstraction
levels provided by Lisp and this puts their design and their coding into a
context where inefficiencies are more clearly highlighted and potentially
avoided. Given the two different design contexts provided by Lisp and C, is
it really possible to make a Lisp compiler that is anywhere as smart as a C
programmer? Can you compile the high-level abstractions of lisp into
implementations that are able to hard-code data-dependent computations?
Does your efficient, fast, cons-free lisp code become so declaration- and
cruft-laden that you might as well be writing in C??

Please post responses. (i hope they don't autoexpire, i'm leaving on xmas
vaxcation tomorrow...)

PS: speaking of other compilers I've dreamt about, does anybody have any
thoughts about a Motif / Xtoolkit --> Raw X11 compiler? In addition to
compiling out indirections that are inherent in the Xtoolkit, you could
declare/encapsulate a defined interface to variable resources in a
particular user-interface module and use this to factor out common and/or
constant resource useage in the Xtoolkit.  This is currently a problem --
witness hacks such as "gadgets" and "flattened widgets". Maybe (snicker)
UIL can be extended to do this?  The Xtoolkit is currently very much an
"interpreter" so maybe a full-blown compiler, rather than a translator is
in order...

-------------------------------------------------------------------------------
	    Niels Mayer -- hplabs!mayer -- mayer at hplabs.hp.com
		  Human-Computer Interaction Department
		       Hewlett-Packard Laboratories
			      Palo Alto, CA.
				   *