[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


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.

    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
    - 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