LispOS and C

[Harvey J. Stein]

Fare Rideau writes:
 >  Of course, if you modify the compilers with just that in mind,
 >  you can get them to produce compliant C code. But
 >  (a) arbitrary C code doesn't fit this requirement
 >  (b) the guards in the C code to make it compliant are likely to prevent
 >  optimization and break any interest using C to begin with
 >  (c) the semantics of C are not very well defined, so that outputing
 >  truely portable code with hard constraints is hard
 >  (what about pointer/integer sizes/etc model, flushing behavior
 >  wrt non-local exits (-> volatile), stacks and persistence, etc).

1. What are you comparing to?  Are you claiming that a compiler which
outputs native code is more portable than one which outputs C?

2. We're assuming some sort of standard API for talking to the OS.
Given the API, one could just as easily add this API to any of the
Scheme implementations I mentioned, and write the persistent object
store in Scheme.

3. This whole discussion is an idiotic waste of time anyway.  As far
as I'm concerned, most people seem to be happy with (and (or CMUCL
ACL) (or Linux BSD)) as a starting point.  I'm perfectly content to
have CMUCL as a base because a) I've been told that its compiler
produces blazingly fast code, and b) as much as I like Scheme, I'd
prefer that as much code as possible be written in a standard
language, and Scheme doesn't have enough of the features as standard.
Sure, we could pick a Scheme implementation and add the necessary
features, but a) then the code would be more tied to a specific
implementation, and b) we'd have to spend time implementing these
features that already come with all Common Lisp implementations.

 >  (d) because you do might do legal C things that C programmers never do,
 >  C compilers might break on your code [see occasional releases of OCAML
 >  with warning "don't use version <foo> of GCC, but downgrade or upgrade
 >  your compiler"]

Every time I've seen this sort of thing happen, it's because of a new
bug that appeared in version <foo> but was fixed in <foo>+1.

-- 
Harvey J. Stein
Berger Financial Research
abel@netvision.net.il