T-Tools

[Robert Nix <Nix at YALE>]

I found this in the T-Discussion archives:

    Date:    17-May-82 3:05PM-EDT (Mon)
    From:    Chris Riesbeck <Riesbeck>
    Subject: walk/mapcan
    To:      Kelsey
    Cc:      Collins, Odonnell, Rees, T-Discussion

    O'Donnell pointed me to your definitions of MAPCAN and FOR on //alpha.

    ...

    //beta/usr/riesbeck/utils.t contains the various TLisp utilities I've
    been bringing over, including LOOP, PRELIST/SUFLIST, MSG and so on.
    You might be interested and/or have coding or naming suggestions.  Names
    right now are TLisp, but I don't care.

    <RIESBECK>TLISP_TO_T.LSP has functions to rename and reformat
    the more obvious functions, and warn about things like SET and DF.
    See <RIESBECK>TLISP_TO_T.DOC.

    Greg Collins was also bringing up some utilities for T on the VAX.
    Before more wheels are reinvented, we should centralize a list of
    what's been done and what's about to be done shortly.  Is anyone else
    doing this kind of thing?
    -----------

Is anyone else doing this kind of thing?

Yes, they are!!!  Unfortunately, I didn't know about Chris's LOOP macro
until I had just about finished mine-- let this be a lesson to those who
skim and delete their mail when they return from a trip.

We should start a mailing list, T-Tools, for announcements of packages of
general interest to T users.  The sources, documentation, and LAP files for
these packages should be maintained and documented in a central directory,
say <F.T.TOOLS> on one of the -20s for now.  Shadow copies of all of these
files, plus object files, should be automatically distributed to several
standard locations on the Apollos and VAX(s).  When T moves off the -20,
T-Tools should still be centrally maintained on some Apollo or VAX.

Without centralization and semi-automatic administration, the only
effective contributors to T will be Rees and Adams.

Some sample packages:
    - Common macros: FOR, LOOP, etc.
    - Data structure hacks: sets, priority queues, hash tables, etc.
    - Data structure browsers.
    - Readers.
    - Process manipulation for the Apollos and VAXs.
    - Display utilities for the Apollos and VAXs.
    - System call utilities (data structure definitions, etc.)
    - FFT, Matrix multiply, ...

And we must, of course, have Programming Standards:

    - Every package must be completely documented.  This documentation
      must be in Scribe-able form, using standard T Manual conventions.
    - Names must obey T conventions.
    - All "public" functions must do dynamic type and bounds checking
      on entry.
    - 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
      it.
    - Every package must be compiled, and be as efficient in time and
      storage as possible.  Every macro must generate efficiently
      compilable code.
    ? Every package should obey the T object-oriented programming standards.

                                            -- Bob Nix
-------