Please make internal DEFINE's more like top-level ones.

[philmtl!philabs!linus!ramsdell@uunet.uu.net (John D. Ramsdell)]

Pavel correctly gives the meaning of top-level definitions.
In article <890503-103409-9762@Xerox> Pavel.pa@XEROX.COM 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.

Clearly, it is not a meaning preserving transformation to replace all
top-level DEFINE's by a LETREC form.  At the top-level, the order in
which DEFINE's are given counts.  People really write code like:

			(define a 3)
			(define b (* a a))
			... code that uses b.

Internal DEFINE's are currently defined to be syntactic sugar for
LETREC.  That is, the order in which internal DEFINE's are given does
not count.  It is illegal to write the following code:

			(let ()
			  (define a 3)
			  (define b (* a a))
			  ... code that uses b).

My continuing question is why treat internal DEFINE's differently from
 from top-level DEFINE's?  Why not give internal DEFINE's same
semantics as given above?  Those who want LETREC like semantics can
use LETREC.
John