Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!lll-winken!uunet!philmtl!philabs!linus!ramsdell From: ramsdell@linus.UUCP (John D. Ramsdell) Newsgroups: comp.lang.scheme Subject: Please make internal DEFINE's more like top-level ones. Message-ID: <52382@linus.UUCP> Date: 5 May 89 11:41:58 GMT References: <890503-103409-9762@Xerox> Reply-To: ramsdell@mitre.org Organization: The MITRE Corp., Bedford, MA Lines: 41 In-reply-to: Pavel.pa@XEROX.COM's message of 3 May 89 17:33:55 GMT 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') ...) 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 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