C->LISP

[Fare Rideau]

>>: Fare Rideau
>: Paul Prescod

First off, let me remind that *nobody* ever
proposed C->LISP as a short-term project,
as we already run on top of Unix anyway...

> If anyone gets enough of the Unix API up and running to allow a
> C->Lisp->Binary compiler to compile TeX (or whatever), then someone will
> use it to compile GCC.
>
Which would be utterly useless, but for cross-compiling C programs to
foreign targets, since the native LispOS apps will have such
a different low-level calling convention than GCC output.
Well, of course, parts of GCC could prove interesting, if adapted.
That won't be any easier work than C->LISP...

> The C Library and Unix API can be provided
> through a simple wrapper on top of the library that runs TeX.
>
You call a platform-specific assembly-level Unix emulator "a simple wrapper"?
Come on! The interest of C->LISP is precisely that *in the long run*,
we want to get rid of Unix altogether, and support architectures
that UNIX can never hope to ever ever support (again: MISC clusters),
yet be able to recycle legacy software.
Nobody ever pretended that this was a high-priority project.

> As long as LispOS can run platform-binaries at all, [C->LISP not needed]
>
Indeed, no one ever said the contrary,
and as we'll be running LispOS on top of BSD/Linux/whatever,
C->LISP is not needed yet.
We have been looking beyond this time.


>> 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."
>
*Bzzzzt* wrong! C->LISP is a decidable problem. *Optimal* C->LISP isn't.
But do you believe that "Optimizing C Compilers" deliver optimal code?
"Halting problem": are you confident that the routines you write will halt?
   The whole point is to have tactics that can
*in as many cases as possible*, *with interactive human hints*,
factor C programs into a generic high-level program
used with specific low-level bindings,
so we get just throw the Cish low-level garbage away,
and keep the "substantifique moelle" of the program.
   I'm sorry that too many people fall in the same trap as you.

> 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.
>
Add "in all cases" to your first sentence, and everyone will agree.
Happily, (1) we only have to deal with a finite amount of legacy software
written by people without much imagination, and
(2) we don't require the translator to work as a black-box,
but recommend interactive (and persistent ;-) human aid.

> You are describing an "optimizing decompiler."
>
More than that. A generic code manipulator.

> 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.
>
I don't pretend to get a good C->LISP system by year 2000.
I don't pretend to even begin before year 2000!

>> 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."
>
Depends on what you call AIish. I'd agree for some "AI" "schools".
I do think that a generic program manipulator is a crucial tool indeed,
and that C->LISP would be only one thing it could do as a demonstration.
Semi-automatizing arbitrary useful manipulations could be possible.
Note the *semi-*: human help is always required; only the human is relieved
from the stubborn systematic rewrites that the computer can do with
fast and consistently, so he can focus on the meaningful part.

>>>> 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.
>
It's not much easier, but it's infinitely more useful.

> You must support ALL of the semantics of the Unix APIs
> that the program uses in either case.
You precisely said it: *that the program uses*.
For a black-box emulator, this means blindly implement everything.
For a high-level tool, this means you only need do what's required,
and can do program-specific transformations.

> 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."
>
Because they ease writing the API.
"Shit, the application writing is the hard part,
why did I waste time with all that LispEnv/LispOS stuff".

>> 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.
>
ML people need no LispOS if their programs are to be run in Unix black-boxen.
So tell me, what do your "native LispOS compilers" look like?
How do ML code get interfaced with Lisp code?

>> 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.
>
Sure. But do you want LispOS to depend on C compilers for ever?
Or what will you do with all that legacy software that people WANT to recycle?

> Those that have a way to ship C applications
> in a low-level retargable binary (e.g. GCC internals) should be allowed to.
>
Sure, if they need Unix/Win/Mac, they can get it already.
No need for LispOS.

> 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.
Uh? Black-boxes are commonly done and not understood.
The principle of black-boxen is precisely
that no one is allowed to understand,
and instead must stubbornly follow a paranoid low-level protocol.


> There are
> literally dozens of programs that emulate one OS on another -- even
> across processors.
>
And that's precisely what we don't wanna do. Black box emulation
is a concept for inefficient proprietary software
that burden us with legacy software and hardware design.
Code manipulation is the design of the future,
that allows free software to get abstracted off its past limitations,
and to adapt to arbitrary new environments.
Tell me when you write an efficient BloatedVonNeumanMachine emulator
on a cluster of MISC processors...

> Can you point to a decent C/C++->Lisp translator that
> produces idiomatic, maintainable Lisp code from arbitrary (relatively)
> maintainable C/C++ code?
>
None yet. Can you point me any LispOS that runs on vanilla hardware?
None yet. Does it mean it can't exist?

> In short: issues of programming language and operating system should be
> relatively orthoganal.
>
Turing Tarpit: it always is. You solution is exactly the Unix way:
"let us provide a blind paranoid stupid low-level Unix box emulator".
Mine is the contrary: instead of (just)
a machine-dependent *low-level* standard,
provide with a *high-level* way of unifying programs accross languages.

> 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*.
>
Agreed. How does writing a C->LISP translator make it "exclusive"?
Doesn't a generic code manipulator
ease the use of programs written in any language rather than forbid it?
Have you deduced that I would have proposed
that writers of low-level Unix emulators should be hanged?

== Fare' -- rideau@ens.fr -- Franc,ois-Rene' Rideau -- DDa(.ng-Vu~ Ba^n ==
Join the TUNES project for a computing system based on computing freedom !
                TUNES is a Useful, Not Expedient System
URL: "http://www.eleves.ens.fr:8080/home/rideau/Tunes/"