C->LISP (was Re: Project list)

[Paul Prescod]

Fare Rideau wrote:
> 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.

I have two words for you: "halting problem." I do not believe that it is
feasible to write a program (even in Lisp!) that can reliably recover
the high level semantics of a program and "improve" it in any
significant sense. You are describing an "optimizing decompiler." If it
is possible, though, then you should write one that automatically fixes
the year 2000 problem and make a lot of money as a consultant over the
next two years.
 
> 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.

I think that if LispOS's plan to take over the world has a crucial
component that depends on something "AIish" then it is trouble. I take
"AIish" to be shorthand for: "I don't know how to do it and I don't
think anybody else does, but maybe I could figure it out if I thought
about it enough."

> >> 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.

And doing a "high level code manipulation" version isn't any easier than
doing a low-level black-box implementation either. You must support ALL
of the semantics of the Unix APIs that the program uses in either case.
But in the "high level code manipulation model" you must also do the
"high level code manipulation" to get you to the point of saying: "Shit,
the APIs are actually the hard part... why did I waste time with all of
that code manipulation stuff."

> >> 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?

I would expect support through compilation to Unix binaries, through
compilation to Lisp and through native LispOS compilers. People have
different needs.

> Do you mean that everyone should to produce binary for every platform?

Those that have any easy way to produce binaries for every interesting
platform (which is to say, everyone) should be allowed to. Those that
have a way to ship C applications in a low-level retargable binary (e.g.
GCC internals) should be allowed to. Those that have an easy way to
convert C code to Lisp code (AFAIK, nobody) should also be allowed to.
Since the hard part is emulating the API, there is no reason to restict
any of these paths from Unix to LispOS.

> How do you imagine interaction between software components written
> in different languages?

If they are old Unix apps then they use Unix-style IPC. What else could
you do? Would your AIish program notice that a C program is sending an
array of numbers to a Lisp program through stdio and send a Lisp vector
of numbers instead?

> 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?

YES! Black-boxes are well understood and commonly done. There are
literally dozens of programs that emulate one OS on another -- even
across processors. Can you point to a decent C/C++->Lisp translator that
produces idiomatic, maintainable Lisp code from arbitrary (relatively)
maintainable C/C++ code?

In short: issues of programming language and operating system should be
relatively orthoganal. I should be able to use any programming language
to program for any operating system. The point of LispOS is to have an
OS that is *optimized* for Lisp not *exclusive to it*.
 
 Paul Prescod