Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!bloom-beacon!spt.entity.COM!alms
From: alms@spt.entity.COM (andrew lm shalit)
Newsgroups: comp.lang.scheme
Subject: semantics of DEFINE
Message-ID: <8905011321.AA03861@spt.entity.com>
Date: 1 May 89 17:21:40 GMT
References: <59021@yale-celray.yale.UUCP>
Sender: daemon@bloom-beacon.MIT.EDU
Organization: The Internet
Lines: 31


   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:

   . . .
   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.
   . . .
   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??

How about a general aversion to the notion of "top-level environment"?  When
you introduce first-class environments, and programming tools for using
them, the notion of "top-level" starts to change.  Just how it changes
depends on how the environments and programming tools are designed.

Do you have a problem with the following, aside from the general aversion
to SET! ?

(define frob nil)

(let ((x (mumble1))
      (y (mumble2)))
  (dset! frob (lambda (z)
               (list x y z))))