[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Naive T Design Questions
Date: Wed Apr 27 05:35:21 1988
From: Olin.Shivers at CENTRO.SOAR.CS.CMU.EDU
VALUES is a better name.
OK, I'm sold. I'm glad you didn't say it was a good name.
Or how about IDENTITY? Just kidding.
Could we store such a library of stuff on prep?
Prep will probably be going away, so the AI lab sun file servers would
be a better choice. All you need is someone at MIT to volunteer to
administer the thing.
But you *do* have to worry about multiple packages if you are doing a
"real" CommonLisp implementation/translator. Which is useful, not because
programming in CL is fun, but because there are a lot of CL programs out
there that would be useful tools for Scheme programmers.
Implementing Common Lisp in T would be possible --- all the right hooks
are there, I think --- but doing enough to allow execution of any but
the most trivial programs would be a major undertaking. If someone
wants to volunteer, fine, but as usual with this kind of thing, manpower
is very limited and other things are higher priority. My highest
priority right now is making T support scheme well, which it currently
For anyone contemplating the task, I have a few suggestions:
1. Take a look at prep:/t/junk/cl/*.t.
2. Talk to the folks working on Butterfly Lisp at BBN. They have
implemented Common Lisp on top of MIT's C Scheme, which has many
similarities to T (syntax tables and environments work the same way).
I heard a rumor that some of their code would become publicly available.
3. Don't try to make packages look like environments; you're bound to
lose; too many Common Lisp programs depend on being able to go from
a symbol to its value, which is meaningless in T. Common Lisp
bindings should all live in a single global
environment, just like they do in Common Lisp. Symbols FOO::X
and BAR::X must be distinct T symbols. I suggest using different
symbols for function bindings, e.g. \#\'FOO::X would be bound in the CL
environment to the function binding of X in package FOO. Higher tech
of course would be to create a new datatype for CL symbols and teach the
compiler about them. There probably ought to be an option in syntax
tables to let one change the way combinations are interpreted, but
I don't think there is.
4. To do keywords properly you'll need to teach the object file
dumper/loader about them. Probably not hard to do. Hacking the
evaluator and compiler front end is trivial; just define an appropriate
"atom expander" for your syntax table. Look at the sources for
the scheme compatibility package.
I have just spent more time on this than I wanted to.