Recoding Lisp programs in C

[preece at ccvaxa.UUCP]

> /* Written  8:39 pm  Oct  5, 1985 by gwyn at BRL.ARPA in ccvaxa:net.lang.c
> */ If the code needed to be done in LISP in the first place, then any C
> translation is going to have to provide garbage collection anyway.
----------
The key word there is "needed."  it may well be that Lisp provided
a more efficient environment for developing the application even if
the application didn't rely on especially Lisp-ish features like
garbage collection, type mutability, and symbols.
----------
> I once toyed with the idea of providing a set of C library routines to
> support LISPy programming, but it seemed too weird to me.
----------
If a C environment with similar capabilities for dynamic development
were available, many such applications might be written in C to
start with.
----------
> Why not just use a good LISP compiler instead, especially since the
> direct translation into C will be much less maintainable than the LISP
> source.
----------
The Lisp environment is likely to be loaded down with features that
are not strictly needed for the running of the application.  Lisp
compilers generally produce code that runs within the Lisp environment,
not as stand-alone applications (some do).

Of course, the translation to C allows the developer an obvious
opportunity to rework the application to preserve needed features
while eliminating unneeded flexibility.  I suspect the rewriting
is as important as the change in language.


-- 
scott preece
gould/csd - urbana
ihnp4!uiucdcs!ccvaxa!preece