Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cs.utexas.edu!uunet!yale!Ram-Ashwin
From: Ram-Ashwin@cs.yale.edu (Ashwin Ram)
Newsgroups: comp.lang.scheme
Subject: Re: semantics of DEFINE
Message-ID: <59114@yale-celray.yale.UUCP>
Date: 2 May 89 14:06:32 GMT
References: <59021@yale-celray.yale.UUCP> <8905011321.AA03861@spt.entity.com>
Sender: root@yale.UUCP
Reply-To: Ram-Ashwin@cs.yale.edu (Ashwin Ram)
Organization: Computer Science, Yale University, New Haven, CT 06520-2158
Lines: 40
In-reply-to: alms@spt.entity.COM (andrew lm shalit)

In article <8905011321.AA03861@spt.entity.com>, alms@spt.entity.COM (andrew lm shalit) writes:
>    Date: 30 Apr 89 20:39:25 GMT
>    From: Krulwich-Bruce@yale-zoo.arpa  (Bruce Krulwich)
> 
>    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.

This is a good argument against DEFINE in general, not against DEFINEs within
LETs in particular.  A top-level DEFINE always assumes that you want to
side-effect the "top-level environment".  What you're really saying is that
DEFINE should take an extra argument, which would explicitly specify the
environment in which the definition should take place.

T does provide such a function, called *DEFINE.  DEFINE is merely a
convenient syntax for doing a *DEFINE in the environment that the startup
REPL works in, called USER-ENV.  The REPL-ENV can be changed as desired.

To get back to the original point, it seems perfectly reasonable to allow
*DEFINEs to be nested within LETs, which would create a definition in the
environment (which is explicitly specified as an argument to the *DEFINE).
The definition is evaluated (and therefore closed) within the lexical
environment of the LET, as any other form would be.

Given that DEFINE is merely a convenient syntax for *DEFINE in the REPL-ENV,
it seems consistent to let a DEFINE with a LET be a convenient syntax for a
*DEFINE within that LET with the REPL-ENV explicitly specified as the
environment for the definition.

-- Ashwin.