LispOS already under development?

[Martin Cracauer]

Paul Prescod writes:
> Another important feature of the Lisp machines was that programs did not
> pass around data in brain-dead formats like untyped pointers or flat
> strings. They passed around real objects. 

Sure.

> The reason that Lisp on Unix
> is unsatisfying is because everything must be converted in and out of
> Lisp types. 

> This is also a feature of the JVM: everything is an object,

No, it is not. The basic data types of the Java VM are not real
objects. They are flat memory represetations of the value, they carry
no type information not is any information about they or their place
stored in the byte code.

The (Java) compiler at compile time is only one who knows what these
beasts actually are. They definitivly need to be converted to Lisp
data types and the information what and when to convert need to be
explicit in the Lisp code.

For each basic data type, there is also a "real object" type that does
the same, but if you'd stick to those, you're loosing even more speed
and Java interoperablity.

> people only work with strings and pointers when conversing with the
> outside world.
> 
> Presumably the Lisp machines also had rich libraries and applications
> available that fit into the "everything is an object" world. Well so
> does the JVM, and the number of libraries and applications are
> increasing every day.

OK, that's another issue. 

Of course, you don't need to mess with all what I listed above when
you just want to use a Java class. You don't need to use anything than
the published interface then.

To get that, I'd say it's best to implement a Java VM in Common Lisp
and run it inside our native Lisp implementation. But using the Java
VM to runt he Lisp code still have more problems.

Martin
-- 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <cracauer@wavehh.hanse.de>
http://cracauer.cons.org
Fax +49 40 522 85 36