Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!husc6!yale!Krulwich-Bruce
From: Krulwich-Bruce@cs.yale.edu (Bruce Krulwich)
Newsgroups: comp.lang.scheme
Subject: Re: semantics of DEFINE
Message-ID: <59840@yale-celray.yale.UUCP>
Date: 8 May 89 14:37:04 GMT
References: <890503-103409-9762@Xerox>
Sender: root@yale.UUCP
Reply-To: Krulwich-Bruce@cs.yale.edu (Bruce Krulwich)
Organization: Computer Science, Yale University, New Haven, CT 06520-2158
Lines: 62
In-reply-to: Pavel.pa@XEROX.COM

In article <890503-103409-9762@Xerox>, Pavel.pa@XEROX writes:
>Too many people are referring to DEFINE as a form that ``side-effects the
>top-level environment'' for me to keep out of the fray.  In the current
>(unreleased) draft of the Scheme specification, R^(3.95)RS, the following
>definitions appear (my wording):
>
>-- A program is a mixed sequence of definitions and expressions.
>	
>-- The meaning of a program P is the same that that of the following
>expression:
>	((lambda (I*) P') <undefined> ...)
>where I* is the set of variables defined in P (i.e., appearing as the CADR
>of a DEFINE form), P' is the sequence of expressions obtained by replacing
>each definition in P with the corresponding assignment, and <undefined> is
>an expression producing some useless value.
>
>More informally, to execute a program, you wrap it in a big LET binding all
>of the defined variables to useless values, change the DEFINEs to SET!s,
>and evaluate that expression.

OK, the above makes sense for "top-level" DEFINE forms.  Before recasting
my comments from before into the terminology used above, let me define two
catagories of DEFINE forms that are not handled under the above
specification:

        (1) non-top-level static definitions: definitions that are made at
            load/compile/etc time (ie, are static) but are not top-level.
            An example of this is a DEFINE form inside a "top-level" LET 
            form.
        (2) dynamic definitions: DEFINE forms that are executed during the
            execution of another procedure.  An example of this is a DEFINE
            form in the body of another DEFINE form.

My claim is that both of these cases fits cleanly into the specification
given above (by Pavel).  In each case the symbol being DEFINEd would be
bound in the global binding countour (shown above as a LAMBDA, essentially
a LET) and would be SET! at the point where they were to be DEFINEd.  The
new specifications (using the terminology from above) would be:

        A program is a sequence of expressions
        The meaning of a program P is the same as that of the expression:
                ((lambda (I*) P') <undefined> ...)
        where I* is the set of variables defined in P (ie, apearing as the 
        CADR of a DEFINE form anywhere in the tree coresponding to P), P'
        is the sequence of expressions obtained by replacing all appearences
        of the symbol DEFINE [perhaps only those where the variable DEFINE 
        isn't rebound] with teh symbol SET!, and <undefined> is an 
        expression producing some useless value.

The next question is why I think the specifications should be extended to
allow this.  My answers are:

        (1) It adds expressive power to the language.
        (2) Other proposed specifications for non-top-level DEFINEs do
            not add expressive power to the language.
        (3) It is a direct and consistant extension of the semantics being
            proposed (according to Pavel).


Bruce Krulwich