Re: Objecting to the proposed changes

[PSZ@MIT-ML]

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
	    reason.  
	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
	    experience.)

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
	    documentation aids.
	etc.

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.

--Pete Szolovits