[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Objecting to the proposed changes
- To: catch-throw at MIT-MC
- Subject: Re: Objecting to the proposed changes
- From: PSZ@MIT-ML
- Date: Thu, 11 Jan 80 13:09:01 GMT
- Cc: PSZ at MIT-ML, GSB at MIT-ML
- Original-date: 11/01/80 09:09:01 EDT
If MACLISP were at one stroke to become a relatively static (i.e.,
SLOWLY changing) language which was well documented and easily
accessible to new users, I would be less reluctant to take the effort to
go fix old programs, but as it is, I am likely to fix CATCHes today and
something else next month. (Some functionally unchanged code I use in
6.871 absolutely requires yearly maintenance.)
Perhaps we could strike a deal: I will accept the burden of
"modernizing" a lot of old code once, if:
1. All foreseeable incompatible changes to MACLISP are gathered
together at one time, announced together, and made together,
with the good will intent that no other such changes should
come along for a significantly long while without very good
2. A new (complete) MACLISP manual is simultaneously issued so
that it becomes possible to teach the language to new users.
The idea would be to have a "1980" release of MACLISP which
then becomes the standard for the next few years.
(I have been teaching MACLISP to 6.871 students -- after a
fashion -- out of the 1974 manual, scraps of the 1978 manual,
and random system notes. It is a very unsatisfactory
Note that if the hackers agreed to this deal, then it would also be
reasonable to sift through current Lisp and find other things to clean
up. Discussions with JONL come to mind concerning:
1. Flushing the HUNK variable and its effects on EQUAL, etc. by
publishing the USERHUNK or EXTEND facility.
2. Settling on some consistent set of function and macro
definition and memoizing facilities.
3. Standardizing various macro packages and deciding the
status of all the NIL extensions to MACLISP.
4. Implementing a sheme of physical/logical character mappings
which would permit various packages to be written with
syntax using logical character sets independent of each
other and several to be used together by mapping their
characters into the physical alphabet. This would be a
generalization to the various #(, #< etc. crocks.
5. Standardizing the inclusion and "x-time eval" mechanisms of
MACLISP (I prefer LSB). Maybe adding some on-line
I am a reasonable man, ready to bargain. But I do think that something
along the above lines, including a renewed commitment to current,
coherent, and consistent documentation, is essential.