Naive T Design Questions

[Jonathan A Rees <JAR@AI.AI.MIT.EDU>]

    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
doesn't.

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.