Re: control vs constraint

[SHRAGE at WHARTON (Jeffrey Shrager)]

Control and constraint are not the same thing.  A control might be an
audit trail.  This is the type of control that I am talking about.  I
do not (necessarily) mean to disallow any extension to the language, simply
monitored extension.  For example, if I were to go into your MacLISP
base load and shange the MAKE-LIST function all of a sudden in order to
have the arguments appear in the order that I wanted to see them you
would all have cows!  All of your functions would stop functioning! 
Extensions (changes) to the base language that are not carefully thought
out lead to real trouble in the future.  Now, consider having written a
large system with 100 functions or so.  Suddenly you decide to change the
internals of some function or another without regard for who or what calls
it other than the caller that you care about!  Insto-MESS!  There are
a couple of ways around this, 1- always make a copy of a function with a
different name [as *THROW, *CATCH in recent discussion] -- this leads real
fast to a proliferation of functions.  The second way is to keep careful
tabs on what functions call this one and the way that they have to be
changed to match changes in this function.  It is exactly this latter type
of control (auditing function) that I mean should be included in NIL (or
whatever).  I am not against extending the language any more than I am
against GOTOs (which is not very much).  However, the system should provide
a means by which a programmer can FOLLOW, CONTROL, AUDIT, <insert your
favorite sysnonym here> extensions that he or the support personell make!