Things to do

[Scott E. Fahlman <Fahlman@CMU-CS-C.ARPA>]

A bunch of things were put off without decisions or were patched over in
the effort to get agreement on the first edition.  Most of the people
who have been intensively involved in the language design will be tied
up for another couple of months getting their implementations up to spec
and tweaking them for performance.  However, it is perhaps not too soon
to begin thinking about what major additions/changes we want to get into
the second edition, so that those who want to make proposals can begin
preparing them and so that people can make their plans in light of what
is likely to be coming.

Here's a list of the major things that I see on the agenda for the next
year or so.  Some are yellow-pages packages, some have deep roots
and require white-pages support, and some are so pervasive that they
will probably migrate into the white pages after a probationary period
in yellow-land.  I'm sure I'm forgetting a few things that have already
been suggested.  I'm also sure that people will have some additional
proposals to make.  I am not including very minor and trivial changes
that we might want to make in the language as we gain some experience
with it.

1. Someone needs to implement the transcendental functions for complex
numbers in a portable way so that we can all use these.  The functions
should be parameterized so that they will work for all the various
floating-point precisions that implementations might offer.  The design
should be uncontroversial, since it is already specified in the manual.
I don't think we have any volunteers to do this at present.

2. We need to re-think the issue of function specs, and agree on what
should go into the white pages next time around.  Moon's earlier
proposal, or some subset of it, is probably what we want to go with.

3. At one point HIC offered to propose a minimal set of white-pages
support for efficient implementation of a portable flavor system, and to
supply the portable part.  The white-pages support would also be usable
by other object-oriented paradigms with different inheritance schemes
(that's the controversial part).  After a brief exchange of messages,
HIC got super-busy on other matters and we haven't heard much since
then.  Either HIC or someone else needs to finish this proposal, so that
we can put in the low-level support and begin playing with the portable
implementation of flavors.  Only after more Common Lisp users have had
some opportunity to play with flavors will it make sense to consider
including them (or some variation) in the white pages.  There is a lot
of interest in this out in user-land.

4. We need some sort of iteration facility more powerful than DO.  The
existing proposals are some extensively cleaned-up revision of LOOP and
Dick Waters' LETS package.  There may be some other ideas out there as
well.  Probably the best way to proceed here is for the proponents of
each style to implement their package portably for the yellow pages and
let the customers decide what they like.  If a clear favorite emerges,
it will probably be absorbed into the white pages, though this would not
preclude personal use of the other style.  None of these things requires
white-pages support -- it is just a matter of what we want to encourage
users to use, and how strongly.

5. A good, portable, user-modifiable pretty printer is needed, and if it
were done well enough I see no reason not to put the user-visible
interface in the white pages next time around.  Waters' GPRINT is one
candidate, and is being adopted as an interim pretty-printer by DEC.
The last time I looked, the code for that package was impenetrable and
the interface to it was excessively hairy, but I've heard that it has
been simplified.  Maybe this is what we want to go with.  Other options?

6. We need to work out the business of taxonomic error-handling.  Moon
has a proposal in mind, I believe.  A possible problem is that this
wants to be white-pages, so if it depends on flavors it gets tied up
with the issue of making flavors white-pages as well.

7. The Hemlock editor, a public-domain Emacs-clone written in portable
Common Lisp, is now running on the Perq and Vax implementations.  We
have a lot of additional commands and modes to implement and some tuning
to do, but that should happen fairly rapidly over the next few months.
Of course, this cannot just be moved verbatim to a new implementation
and run there, since it interacts closely with screen-management and
with the file system.  Once Hemlock is polished, it will provide a
reasonable minimum editing/top-level environment for any Common Lisp
implementation that takes the trouble to adapt it to the local system.
This should eliminate the need for hairy rubout-handlers, interlispy
top-levels, S-expression editors, and some other "environment" packages.
We plan to add some version of "info mode" at some point and to get the
Common Lisp Manual and yellow pages documents set up for tree-structured
access by this package, but that won't happen right away.

8. Someone ought to put together a reasonable package of macro-writer's
aids: functions that know which things can be evaluated multiple times
without producing side-effects, type-analysis hacks, and other such
goodies.

If you have items to add to this list, let me know.

-- Scott