C->LISP

[Paul Prescod]

Fare Rideau wrote:
> 
> >>: 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?" Presumably the person is going to want to
run TeX on LispOS within the first few years of its existance, not some
arbitrary time into the future. Therefore my answer is "write a Unix
emulator for LispOS" because OS emulators are well-understood, even if a
pain in the ass to write. Presumably LispOS would be sufficiently
flexible that Unix features would be readily implementable, even if
radically different than the default way of doing things.

Your answer *seemed to be* "write a C->Lisp converter." Which, given
your response above seems to mean: "Do without TeX for a very long time
and THEN write a C->Lisp converter to get access to it."

I'm answering not you in particular, but all of the people who responded
about C->Lisp converters.
 
> > 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.

GCC outputs calls to a *library*. That library can be written in either
C or Lisp and provides the translations from C calling conventions and
parameters to Lisp calling conventions and parameters. Translating
calling conventions and parameters is easy compared to implementing the
semantics of the Unix APIs on LispOS. But implementing these semantics
is the only way to get TeX et. al running!

> *Bzzzzt* wrong! 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. I mention the halting problem not because I
think that a C->Lisp program is undecidable (or even difficult) but
because as soon as you try to recover the *meaning* of a low-level
program you are venturing into halting problem territory. 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.

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

Anyhow, it is clear to me that you are talking about something very
different from others in this thread. 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.

 Paul Prescod