[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Jonathan Rees on OO
I think one thing that lisp really needs that C and C++ have is the ability
to lay out data types in a very low-level fashion. This is not something
that should be done lightly and perhaps not at all unless you are a very
experienced programmer, but it's critical to getting really good
performance in many cases. I suspect the reason why lisps don't have it is
that it can interact in hairy ways with the garbage collection scheme,
which makes life much harder than it is in C/C++. There are also issues of
array bounds non-checking etc. and then before you know it all safety bets
This leads naturally to the idea of having a "low-level lisp" in which such
programs can be written and then used safely by the standard lisp. I
believe this is how prescheme/scheme48 worked (works?), although this was
done just to bootstrap the system AFAICT. There is also an analogy to C#
and Modula-3 (garbage collected languages that allow for "unsafe modules").
I would really like it if Arc offered some facility like this, but I don't
understand the issues well enough to know if it's feasible or not.
> Date: Thu, 27 Dec 2001 21:07:53 -0800 (PST)
> From: Paul Graham <email@example.com>
> Sorry for taking so long to reply, jrb. I agree with
> you more than you might guess.
> I agree strongly with you that a language ought to let
> users do what the language implementors did. This is
> what made me love Lisp in the first place. I think
> you cannot go too far in this direction.
> McCarthy didn't say anything about types. And so the
> first Lisp implementations got Algol types: certain
> primitives, and that's it. I don't like that. You
> need types to write any actual program, and if you're
> going to have types you should have them in the Lisp
> spirit. I.e. users can define new functions that get
> treated like the built-in ones; why can't they define
> new types that do too?
> I worry when I hear the word "class". Why do we need
> that word? Users should be able to define types, and
> indeed as far as possible the code defining the built-in
> types should be written in the language.
> I've thought of just making the only really primitive
> type in Arc be a block-o-bytes, and defining nearly
> everything else on top of that. Not sure how well that
> would work.