[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: Nix at YALE
- Subject: Re: T-Tools
- From: John R. Ellis <Ellis at YALE>
- Date: Mon ,1 Jun 82 23:12:00 EDT
- Cc: T-Discussion at YALE
- In-reply-to: Nix's message of 1-Jun-82 10:45PM-EDT (Tue)
Bob's suggestions were all good (except one). Maybe he is volunteering
to become the T Big G?
- A strong effort should be made to make each package stand on its own.
Ideally, a particular package should not require the presence of any
function outside of the T core to run. Note that this is not a
restriction on the macros it uses, just the object code created from
What's the point of packages if you can't use them? If the packages are
good, people will want to use them for building other packages. E.g.
a database package might want to invoke the process manipulation package;
I'm sure other people can come up with better examples.
The only reason for making a package "stand alone" is because there are
few good source code and module control tools of the sort found for Mesa
or Unix. But even a primitive system (just slightly more sophisticated
than ELLISP BUILD and REQUIRE) would be adequate for the initial T
community. For example, it would be sufficient (and easy) to put REQUIREs
of dependent modules at the top of each module. For the most useful
packages, you would quickly discover obvious holes where people left out
Just think if the BLISS runtime library or CEDAR didn't have internal