Project list

[Jordan Henderson]

Paul Prescod wrote:
> 
> Jordan Henderson wrote:
> > One other project that might be started would be a C->Lisp compiler
> > project.  Here are a few goals I think might be beneficial for this
> > project.
> 
> 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. 

I have a "gut feeling" that this compiler would produce sub-optimal results.
So what.  I don't think much time should be spent making this an excellent
C++ development system.  The idea is to get a large body of >working< Lisp
code.  I don't know that the initial performance of the translated apps would
be so bad as to be unusuable.  I think the people who have all the TeX laying
around just want to be able to access it.  I doubt that this compiler would
generate code that ran on modern processors much slower than the native C
compilers running on Unix ran just a few years ago.  I think that would be
acceptable performance.  Besides, once we have >working< apps translated from 
C, we can perform hand optimizations on the particularly slow parts in >LISP<.  
Remember LISP?  Let's keep focused here.  I for one don't want to end up with
a Unix knock-off which has a really good Lisp environment bolted on to it.
If we maintain our focus on developing infrastructure in Lisp, I don't think
that will happen.


> 
> It seems much easier to me to just implement a C++ compiler on LispOS.
> On any modern processor the C/C++ program can be firewalled from the
> Java stuff and the operating system can be emulated through a set of
> exported APIs. Those APIs must be exported regardless of whether you
> convert to Lisp or compile directly from C++ to binary.
> 
> Supporting C programming tools is trivial. They are already implemented:
> GNU has a compiler for most interesting processors. The difficult thing
> is implenting support for the Unix API. That's what the Cygnus Win32
> project is all about. That must be done whether you convert the code to

I think that supporting a binary representation (for use by the compilers)
of the Unix API on a radically different OS architecture (which is what I
would like to see) is a great deal of work, and an extra disincentive to
those who might attempt to port the system to new architectures.  Supporting
the Unix API in source form as a translation from C style API calls to our
new OS' object-based services would be far easier.  Thus, the C->Lisp compiler.

The Cygnus Win32 project is a poor proof of concept here.  I think the 
underlying services available to them on Win32 were much more similar that 
what I envision as being available on the new LispOS.  I don't know how 
they did it exactly, but they also had the whole ANSI C Library implemented
for them already (don't know if they used the one MS provided at any point,
or if they still do for that matter).  This being the case, they still are 
pretty far from being able to port all of the Unix stuff to the Win32 after
years of development.  

> Lisp or not. If a C++ program executes a fork() and that gets translated
> into a Lisp (fork), there still has to be an emulation of fork lying
> around so that the function call DOES something.
>  

fork() and the rest of the Unix API has the C style execution model 
in mind that you claim converts poorly to Lisp.  You're willing to buy
the overhead of the necessary conversion of this execution model to the
underlying execution model at this level, but not at other levels.  You
reject it without any measurements of anything, just "my gut feeling it
would be slow".  

I'm excited by this project exactly because I feel it's a chance to get
away from the C/Unix execution model, which has proven to be unreliable,
slow (bloated, redundantly implemented systems) and a hindrance to further
progress.

I'm practical in thinking we can't get away from the past entirely.  There
is the fellow who has the reasonable request to access his TeX files.  Let's
let him access them in an expedient method that also allows us to move those
apps away from the C/Unix execution model that I claim has problems.
>  Paul Prescod
> 
-Jordan Henderson
jordan@neosoft.com