Subject: Re: A modest proposal (long) From: Erik Naggum <erik@naggum.no> Date: 2000/03/03 Newsgroups: comp.lang.lisp Message-ID: <3161052909493352@naggum.no> * 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