Newsgroups: comp.lang.scheme
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!howland.reston.ans.net!gatech!psuvax1!news.ecn.bgu.edu!siemens!princeton!news.princeton.edu!blume
From: blume@dynamic.cs.princeton.edu (Matthias Blume)
Subject: Re: redefinition of builtin procedures
In-Reply-To: qobi@qobi.ai's message of 22 Nov 94 01:48:31 GMT
Message-ID: <BLUME.94Nov22102949@dynamic.cs.princeton.edu>
Originator: news@hedgehog.Princeton.EDU
Sender: news@Princeton.EDU (USENET News System)
Nntp-Posting-Host: dynamic.cs.princeton.edu
Organization: Princeton University
References: <QOBI.94Nov21204828@qobi.ai>
Date: Tue, 22 Nov 1994 15:29:49 GMT
Lines: 94

In article <QOBI.94Nov21204828@qobi.ai> qobi@qobi.ai (Jeffrey Mark Siskind) writes:

  [ long explanation of why top-level redefinitions do not necessarily
    prohibit certain optimizations -- provided there is no interactive
    top-level ]

I very stronly oppose this view.  I was certainly one of those who
pushed the optimization issue.  However, it must be noted that there
is an even stronger reason of why top-level redefinitions should be
eliminated from the language (or at least should be given a different
meaning).

R4RS is quite clear on how to treat top-level definitions.  It
essentially says that a top-level definition of a symbol which is
already bound must be treated as a top-level *assignment* to the
corresponding variable.

The rationale for this is quite clear -- if an implementation treats
all global variables as mutable, then all code referring to those
variables remains valid -- even after a re-definitions (which really
is just an assignment) occurs.

The trouble with this is that R4RS silently assumes that all top-level
definitions are variable definitions.  Unfortunately, things become
very different if we add macros to the language.  The macro appendix
of R4RS doesn't address this issue at all, and the main body of the
document doesn't address macros at all.

Macros -- and more generally: top-level definitions, which modify the
denotation of global symbols -- cause the simple model to be
inconsistent.  (The denotation of a global variable is the location
this variable is bound to.  By definition, re-defining a global
variable in R4RS doesn't modify the denotation, it only modifies the
store.)  Changing the denotation of a global symbol means that a
compiler potentially generates different object code for sources
referring to that symbol.

Re-defining a global variable affects all code -- past, present, and
future -- which refers to this variable.  Re-defining a global macro
usually doesn't have this effect.  This is what I call ``inconsistent''.
Many Scheme systems allow to ``declare'' certain global variables to
be ``integrable''.  This also modifies the denotation of that variable
-- the denotation now is a description of when and how to
``integrate'' calls to the procedure in question.

I would like to propose an interactive top-level, which works very
much like the interactive top-level of SML: Every definition
conceptually makes up a new nested scope.

Of course, this does not allow mutually recursive procedures to be
defined like in:

	(define (a ...) ... (b ...) ...)
	(define (b ...) ... (a ...) ...)

because the occurence of B in the definition of A refers to the
*previous* definition of B (or is an error if there wasn't such a
definition).

SML uses special syntax (``and'') to allow mutually recursive
definitions.  I would recommend using the (begin <definition> ...)
syntax in Scheme for the same purpose.  (Preferrably all important
definitions occur within separate *modules*.  This is an even better
way to put syntactic brackets around definitions, which belong
together.)

Some people will definitely argue that the new scheme inflicts
limitations on interactive program development.  I have the following
answers to these complaints:

	1. On todays fast machines interactive program development is
	   by far not as important as it is said to be.  One can
	   easily afford to re-load or re-compile a source file if one
	   needs to.  (I almost never hack Scheme code directly into
	   the running interpreter, even now.)

	2. There is always SET!.  This allows to ``re-define'' global
	   variables THE SAME WAY AS IT IS DONE NOW.  It doesn't work
	   for  macros or ``integrable'' procedures (for a very
	   good reason), but it doesn't work now either.

The bottom line is that I simply do not see any good reason for
allowing top-level redefinitions, while I see several very good
reasons for banishing them.

The views expressed above have been shaped during the development of a
Scheme module system which will be part of VSCM.  If the RnRS
committee decides to retain an inconsistently behaving interactive
top-level, then it is very likely that VSCM will no longer be a
conforming implementation of RnRS.  (This is of course not a threat --
it's just a fact. :)

--
-Matthias
