[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Extending the address space of MIT Cscheme (long reply)
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
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
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
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?