C->LISP (was Re: Project list)

[Fare Rideau]

>>>: Jordan Henderson's proposed a C->Lisp compiler
>>: Paul Prescod (in two messages I intermixed)
>: Christopher (Chris) J. Vogt


>> Ugh. My gut feeling is that this code is going to be slow. C's execution
>> model is very different from Lisp's, and constructs that run quickly on
>> C will run slowly on Lisp and vice versa.
>>
Surely an unoptimizing C->LISP compiler can generate real awful code.
Actually, the best way to obtain good code is
to not straightforwardly generate code,
but to "understand" what the C program is doing,
and write better, equivalent code in LISP.

Granted, this means that a good C->LISP compiler
involves lots of knowledge and understanding,
which implies that the compiler be a specialization
of a generic AIish code manipulation tool.
One advantage of LISP is that it allows the human to insert
his knowledge and understanding interactively,
whereas you'd be stuck in a C-based code manipulation tool,
which would be limited to stupid straightforward code generation only.


>> If you radically change the
>> code so that it is optimized for Lisp compilation then it will become
>> unmaintable.
>>
Why? It seems to me that maintainable code is precisely the one
that allows the best optimization,
given a compiler that can accept compilation hints...


>> [Just reusing existing C/C++ compilers]
>>
Such compilers heavily rely on the Unix process model,
so that running their output code basically means
that there's a Unix kernel always running below/next-to/on-top-of LispOS.


>> The difficult thing is implenting support for the Unix API.
>>
Yup. But doing it with a paranoid low-level black-box implementation
ain't any easier than doing it through high-level code manipulation.


>> I think that there is something very wrong with an operating system
>> requires new applications to be "compiled" to the language that the
>> operating system is written in just to run.
>>
What kind of support will you give to, say, ML?
Do you mean that everyone should to produce binary for every platform?
How do you imagine interaction between software components written
in different languages?
Do you think that it's easier to implement and support a paranoid black-box
(on hardware that allows it)
than to implement and support semantic-based code manipulation?


>> Why would the fact that the operating system is written in Lisp
>> stop programs written in C from working?
>>
Because Lisp is high-level and C low-level,
so that either you're slowly emulating C back into LISP,
or you're providing a Un*x/whatever kernel to run C code.

Of course, a C->LISP is a long-term project assuming we want to get rid
of the underlying C-ish OS nonsense. Not a immediate priority.


>> The set of OS functions available might be different, but
>> that's a problem whether the source is in C or Lisp. C->Lisp->Binary
>> cannot be substantially easier than C->Binary.
>>
Easier, not (C->Binary has zero cost, as you showed).
More useful, yes.
It is about recycling unsafe code that needs a low-level interface into
safe high-level code that can freely interface with a high-level interface.



> I agree that you don't want c->lisp translator.  I would also add that Is
> think you *do* want to C compiler to generate some Lisp like code.
>
[Just BTW, GCC *does* produce a Lisp-like code, the RTL,
though it is a very low-level kind of Lisp]

> For instance, Maybe it should generate code to do bounds checking,
> Maybe the data should be typed, just like lisp, and garbage
> collected.  Maybe this could be a compiler switch.
>
Surely, a C->LISP compiler would have lots of different tactics.
Code that could be "understood" enough being better translated
than code that could not.

http://www.eleves.ens.fr:8080/home/rideau/Tunes/HLL/metatranslator/Ctranslator/Ctranslator.html


#f