C->LISP

[Fare Rideau]

We have been many subscribees to propose a C->LISP compiler
(Kelly Murray, Harvey J. Stein, Jordan Henderson, and I, at least)
as a way to recycle existing drivers or applications written in C
and C-implemented languages to run natively under LispEnv/LispOS.


A C->LISP compiler is clearly a very long-term project:
to get awful stupid slow code is doable,
but to get maintainable code that can interact with high-level LISP code
is very difficult.
   Surely we could get in touch with research groups
in semantic-based program manipulation.
   A good starting point, of course, is Tom Lord's code in ~twaddle.
There must be other existing software, too. I admit I have searched enough.


>: Jordan Henderson <jordan@neosoft.com>

> One other project that might be started would be a C->Lisp compiler project.
Well, I have long had a WWW page about just that in my Tunes project:
/home/work/moose/TUNES/doc/www/HLL/metatranslator/Ctranslator/Ctranslator.html
The TUNES project also has lots of other subprojects,
and if anyone wants to take over some of them, he's welcome.

> Here are a few goals I think might be beneficial for this project.

> 	* Produce maintainable Lisp from the compiler.
> 
> 	  The idea will be to compile the C code once and throw it
> 	  away.
You just can't do that! Until LispOS takes over the world,
people will continue to maintain and patch their C programs,
and we do want to merge people's bugfixes and improvements
into our translated code, don't we?
This means we must keep a track
of the code transformations done on the C source,
so we can semi-automatically propagate changes through them.
Any modification done on the translated source must be logged, too,
which means a C->LISP project can only be part of a more general
meta-programming environment.


> 	* Have a Lisp->C compiler integrated with the system.
>
> 	  As an adjunct to the Lisp->C compiler, if we had a good
> 	  C->Lisp compiler (there are a lot of starting points for
> 	  this) then we could take large bodies of C code, compile,
> 	  maintain and improve it in Lisp and produce C for other
> 	  environments.  This would make the system practical from
> 	  a business point of view as a development system compatible
> 	  with the rest of the world's systems.
>
> 	  Such a Lisp->C, C->Lisp combo might eventually make variants
> 	  like a Linux port maintained entirely in Lisp possible
> 	  someday.
>
Hey, did you read my posts recently?
I proposed the exact same a few messages away!


> 	  No time should be spent making the resulting C maintainable.
>
Not by us, but I'm sure someone will do if the project is successful,
and we shouldn't make it artificially difficult to him.



> There's no reason why a lot of sub-projects can't be started (ala GNU)
> as long as they all are synergistic with the main goals.
>
> I may be modelling my idea for the greater project heavily on GNU,
> but we could do worse.
>
That's also what I proposed with a NIL counterpart to GNU.
It seems that there are valid objections to the ``NIL'' name though;
maybe you can find a better one (or counter the objections).

Another name that could be given to the whole set of projects
could be "TUNES", of course, if you don't mind merging with my project.
If someone does have objections, be it of container or contents,
I will welcome them, and am ready to fix whatever may be wrong about TUNES.
Not being a born leader, I would even happily hand over project leadership!
The URL is http://www.eleves.ens.fr:8080/home/rideau/Tunes/
However, TUNES may not be exactly what you want,
as it not strictly a LISP project;
it is rather a project for a reflective architecture,
for which Lisp languages are the most adapted
among those that exist currently.


> Speaking of GNU.  I think one thing that would greatly benefit the long-term
> viability of this project would be a manifesto, a creed to rally behind.
> Why ARE we involved in a project to do a LispOS.  My feeling is that we
> see all the problems that have been spawned by C and other inferior
> languages and we want to replace the OS and the basic tenets of OS design,
> from the ground up, using a better, more flexible, more adaptable
> substrate, Lisp.
>
> Anyone volunteering to work on a manifesto?
>
Well, haven't you just volunteered?
Of course, I could write a Tunes manifesto, but...

#f