T compatibility with UCI LISP

[James R. Meehan <Meehan at YALE>]

I'm looking for recommendations on the following issue.

  In the process of getting people to move from UCI LISP (TLISP)
to T, there are several things we can do to help. Riesbeck has
already provided TLISP_TO_T, which does source-to-source
transformations and goes a long way in easing the transition.
But there are UCI LISP functions for which there are no T
equivalents. Some of them (e.g., MODCHR) are system-dependent
and must be rewritten from scratch. Others (e.g., SUBPAIR) are easy
to write in T but aren't used very often. A third class of
functions (e.g., PRINA, MAP) are very useful but don't
have short translations in T, therefore taking them out of the
jurisdiction of TLISP_TO_T.

  It seems reasonable to supply a "library" of "useful" T functions
somehow. If they're "really useful," they should become part of T.
Otherwise, we can keep them online somewhere for people to use as
they please. [Perhaps there's no point in doing that. Maybe we should
add everything to the system.] Many of these functions have already
been written by people who have had to move large programs into T.

  When a function is deemed useful enough to become part of T, we
face the question of whether to open-code it in the compiler. For
functions that are quasi-special forms like MAPCAN, this seems appropriate;
for simple, useful procedures (e.g., TCONC), there's not much the
compiler can do. The quasi-special forms like MAPCAN that can be written as
procedures should probably start out that way; we can change the
compiler later if necessary.

  Specific suggestions about the MAP functions:
UCI LISP has 6 MAP functions. You get your choice of returning NIL,
consing, or splicing the results, and you can traverse either cars
of cdrs. T has MAP, which is equivalent to MAPCAR, and WALK, which
is very similar to MAPC. One option is to add library functions
for the other varieties. Another choice is to allow
(FOR (var ON list) ...) in addition to (FOR (var IN list) ...),
thus making it a FOR-loop problem. [A problem with traversing cdrs:
do you keep a separate pointer to the rest of the list, playing it
safe, or do you allow the user to clobber the rest of the list? UCI
LISP plays it safe.] We could also extend FOR-loops to allow INs and
ONs at the same time, and add SAVE-LAST to DO, SAVE, SPLICE,
and FILTER, as in UCI MLISP. Of course we can do all this with LOOP,
but the goal is brevity.
                -------

  My candidates for UCI LISP functions that are useful enough to put
into T, with suitable modifications (e.g., stream parameters):
NEWSYM & friends, READLIST, PRINA & friends, ERRSET, FSCNT & friends,
GETDEF, UNION & friends, TCONC & LCONC, LINEREAD, NODUPLES, SORT,
REPEAT, LSUBST, SUBLIS, TIMER.
-------