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...
>
> Well the question was: "How do I run TeX on LispOS to access all of
> those TeX files in existence?"
>
As long as we are running on top of Linux/BSD, the answer is *trivial*:
just spawn() a process in the host OS!!!
When we have a system that can do most everything without a host,
then it's seriously time to have a C->LISP;
this time can be further delayed by the use of a micro-kernelish approach
where multiple OSes run at once.
   But this time is *eventual*:
we don't want to port Unix to every new platform so as to run LispOS.
Instead, *new* platforms (and progressively, old ones),
will be supported by high-level source-to-source manipulations.
Again, you won't ever write a Unix emulator for a cluster of MISC,
but you can achieve wonderful performance with translated programs.


>>[Porting GCC to LispOS]
>> 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.
>
> GCC outputs calls to a *library* [...only emulation libraries needed...]
>
*Bzzzzt* wrong! GCC does not only generate calls, mind you,
it also generates *code*.
LispOS will most likely have stringent code generation rules,
so as to allow real-time/distributed GC (ever heard about these ones?).
GCC output obviously doesn't follow them.
   Of course, it is imaginable to have GCC support these rules,
but that's a non-trivial job, and breaks many optimizations,
unless high-level code transformations/proofs are done anyway.
If you don't control C code produced, then you're back to building
a low-level Unix emulator, and better just pick an existing Unix kernel.
   Of course, superusers could, as an unsafe operation,
include uncontrolled GCC-compiled code in the Lisp system.
But don't expect uncontrolled C code from even a trivial utility
to not crash LispOS.
   Of course, stealing bits from the GCC backend optimizer
might be a useful hack per se; but that's quite another story.


>> C->LISP is a decidable problem. *Optimal* C->LISP isn't.
>> But do you believe that "Optimizing C Compilers" deliver optimal code?
>
> No, but they don't even *try* to deliver maintainable, readable,
> idiomatic assembly code.
>
(1) this isn't a hard requirement. It's a soft requirement.
i.e. even if the code is not understood, it runs,
but it runs quite better when understood,
so we can start with a dumb compiler,
and progressively extend it, and allow the user to extend it.
(2) this isn't to be done automatically;
the human is there to help. If a human can port the tool,
the computer can help him to it in a provably consistent way,
and relieve him from the stubborn details.

> as soon as you try to recover the *meaning* of a low-level
> program you are venturing into halting problem territory.
>
Ever heard of interaction between man and machine?
Do you imagine that anyone believes that we are going to write a program
that can understand anything without incremental help from the human?

> Program's meanings are defined by what they do.
> Making an equivalent high level
> program that proveably does the same thing as a low level program would
> require levels of understanding of the low level code that are hard for
> a person, much less a computer.
>
If a person can prove it, then he can have the computer prove it.
If he can't, then the low-level program is not to be trusted anyway,
and/or we can run an inefficient translation anyway.

>> 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.
>
> And what happens when a new version of the C app comes out? We port it
> all over again interactively?
>
You seemingly haven't read my previous mail. Please do.
I already answered this question.
Hints: Diff, Reversibility, Morphisms, Persistence, Human Interaction.

> Anyhow, it is clear to me that you are talking about something very
> different from others in this thread.
"Very", I believe not.
"Different", certainly, or I wouldn't dare adding to the bulk of the list.

> I have no problem with a "generic
> program manipulator" as long as it is not the only mechanism for porting
> C/C++ applications to LispOS.
>
I also responded this objection.
You were the only one to even imagine
that it could be the only mechanism for porting C/C++ applications.
It will eventually become the priviledged one, but that's very long-term.

#f