From ...
From: Erik Naggum <erik@naggum.no>
Subject: Re: A modest proposal (long)
Date: 2000/03/03
Message-ID: <3161052909493352@naggum.no>#1/1
X-Deja-AN: 592570417
References: <gat-2902001653240001@milo.jpl.nasa.gov> <ey3ln42j056.fsf@cley.com> <gat-0103001158360001@milo.jpl.nasa.gov> <3160942638240195@naggum.no> <gat-0103001927290001@milo.jpl.nasa.gov> <3160966858202840@naggum.no> <38BECBE4.37DA@iol.ie>
mail-copies-to: never
Content-Type: text/plain; charset=us-ascii
X-Complaints-To: newsmaster@eunet.no
X-Trace: oslo-nntp.eunet.no 952069262 5439 195.0.192.66 (3 Mar 2000 07:41:02 GMT)
Organization: Naggum Software; vox: +47 8800 8879; fax: +47 8800 8601; http://www.naggum.no
User-Agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.5
Mime-Version: 1.0
NNTP-Posting-Date: 3 Mar 2000 07:41:02 GMT
Newsgroups: comp.lang.lisp

* Russell Wallace <manorsof@iol.ie>
| Can you give a reference to this, or summarize the argument in question?

  Pierre R. Mai relieved me (thanks!) of searching for the articles where
  Kent has made this point, but my understanding of this issue is that any
  language that has the ability to do non-local transfers of control needs
  a mechanism to ensure that invariants and pre- and post-conditions are
  maintained even across them.  that is, _if_ you care about maintaining
  invariants and pre- and post-conditions (which could collectively be
  thought of the very sanity of your code), and that's where I extend this
  argument to apply to programmers.  most modern languages now have several
  sometimes _very_ powerful means of non-local transfers of control, such
  as exception handling.  outside of Common Lisp, none of them make sanity
  maintenance convenient, what with all the declarations and "try" blocks
  and everything.  a programmer who doesn't care about the sanity of his
  code and doesn't even pause to consider the consequences of modifying the
  state of a global variable (and they do exist, regardless of what people
  think or do to avoid them -- consider data on disk the ultimate in global
  variables) should just not be programming anything that has side effects.
  and the more we think about this, the more we want heavy-duty transaction
  processing and committing blocks of changes at a time, with roll-back and
  journaling and all that nifty stuff that the database people have figured
  out and automatized for their programmers.  unwind-protect is a similar
  concern for the sanity of code and data.  and binding special variables
  without needing unwind-protect to set and restore the values of otherwise
  mere global variables is on par with automatized transaction processing
  in terms of programmer convenience.  now somebody wants to take that
  convenience away from us with more verbose syntax and added hairiness to
  the language.  consider what database programmers would think about a
  proposal to have to be _explicit_ about every transaction processing step
  _all_ the time.  that's how good programmers should react to any measure
  to abridge the usefulness and convenience of special variables.

#:Erik