Re: Extending the address space of MIT Cscheme (long reply)

[shebs%defun@cs.utah.edu (Stanley T. Shebs)]

Thanks for your message.  It clears up most of my problems with CScheme.

>    Gazillions of builtin types.
>
>What's wrong with that?  It's nice (and ultimately more robust) to
>allow the system to distinguish between various objects with 2, 3, or
>more components.

I was suggesting user-defined types, a la DEFSTRUCT.  Some types are just
not "important" enough to be made into primitives.  User-defined types are
such an important abstraction it's surprising to see CScheme not use them;
it would save a lot in the many switch statements on types.

>1) Using a virtual machine is a common technique these days to
>implement interpreters.  We have made no claim that our interpreter
>will run code as fast as code produced by native code compilers.  Thus
>there is no attempt to make the CScheme interpreter run as fast as
>anybody else's compiled code.  As far as interpreters go, it's not
>great, but it's not bad in terms of speed, but provides much more
>convenience and ease of debugging than any other interpreter I know.
>
>2) Most of the hairy C and macrology arise not from using a virtual
>machine, but from the fact that the PARTICULAR virtual machine we
>chose cannot be conveniently written in C without paying an undue
>penalty.

These two statements seem contradictory - first you're saying that there
is no attempt to make things as fast as compiled code, but that using
functions instead of macros exacts an undue penalty.  I don't understand!

>[...] What's wrong with
>coding a commonly used procedure [FFT] in a language which will make it more
>efficient?

I have no problem with that, but it's the embedding of the procedure in a
language implementation that seems strange.  There are any number of other
ways to provide FFT in C without making it into a primitive function.

>    References to apparent GC in all kinds of strange places.  When I followed
>    them, the trail disappeared in a maze of macros.
>
>Hmm.  Maybe the Lisps you are used to don't check whether there is
>enough space to allocate storage before they go ahead and do it.  They
>can't be very robust.  I'm also surprised that you complain about this
>particular "maze".  It seems pretty straightforward to me.

I found the check for the *necessity* of GC, and it was in the same place
that most other implementations put it.  What I didn't find was how the check
actually got a GC going!  No doubt it will seem straightforward to me too,
once it's pointed out...

>    References to the compiler and Edwin, thus violating every principle of
>    abstraction known to exist.
>
>What?  Please explain, I don't understand what that means.

I'm speaking of edwin.h and com*.c.  Why are they for?