Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!bloom-beacon!SESAME.STANFORD.EDU!mkatz
From: mkatz@SESAME.STANFORD.EDU (Morris Katz)
Newsgroups: comp.lang.scheme
Subject: semantics of DEFINE
Message-ID: <8905011536.AA12423@sesame.Stanford.EDU>
Date: 1 May 89 15:36:20 GMT
References: <59021@yale-celray.yale.UUCP>
Sender: daemon@bloom-beacon.MIT.EDU
Organization: The Internet
Lines: 46


   Date: 30 Apr 89 20:39:25 GMT
   From: Krulwich-Bruce@yale-zoo.arpa  (Bruce Krulwich)

   In article <19890425161147.8.DEATH@MICKEY-MOUSE.LCS.MIT.EDU>, death@ZERMATT
   (Mark A. Sheldon) writes:
   >Allowing DEFINEs everywhere gives us a weird sort of dynamic scoping.
   >Restricting DEFINEs to beginnings of blocks allows us to think of a block
   >of internal DEFINEs as a LETREC (though CALL/CC may expose implementations
   >that don't implement these blocks as a LETREC).  If Scheme is a statically
   >scoped language, then this sort of DEFINE is anathema.  If Scheme is to
   >support dynamic scoping, then I think FLUID-LET is cleaner because I don't
   >have to think about environment mutation.

   A while ago I posted the suggestion that non-top-level DEFINEs do the same
   thing as top-level DEFINEs, ie, side effect the top level.  This allows
   top-level definitions to scope over lexically bound variables, which cannot be
   done in any other way (as of now a single procedure can scope over variables,
   but such variables cannot be shared by procedures); having non-top-level
   DEFINEs side effect the local lexical environment is the same as LETREC
   (perhaps nested) and thus doesn't add any functionality.  This interpretation
   is the one adopted by the current version of T (although it's not an explicit
   decision on the part of the T designers) and I believe is the interpretation
   used by most LISP dialects.  The ability to have global procedures scope over
   variables reduces the number of unneeded global variables, allows hiding of
   internal representations, and (almost definitely) adds alot to the efficiency
   of accessing these variables.

   Most of the responses that I got said either like "well, Abelson and Sussman
   used the 'local' interpretation, so we really should stick to it" or "well,
   local non-top-level DEFINEs add fewer parentheses than nesting LETRECs."  Does
   anyone have other (theoretical or functional) reasons for this decision??


   Bruce Krulwich



Some systems may not have the concept of A top level environment, so this
proposal restricts Scheme in an important way that should be recognized.  If
one has a system that has first-class environments, then a top level
environment may not exist or may be a dynamic, rather than a static, property
of a piece of executing code.  I would far prefer to see local defined removed
from Scheme than have them given the proposed semantics.
					Morry Katz
					katz@polya.stanford.edu