On Thu, 2010-12-23 at 20:39 -0500, Eli Barzilay wrote: > Earlier today, Peter Kourzanov wrote: > > On Wed, 2010-12-22 at 18:36 -0500, Eli Barzilay wrote: > > > > > You're confusing (or mixing) a local binding (let ((eqv? ...)) ...) > > > with an implicit mutation (define eqv? ...). > > > > Is it? > > ...an implicit muatation? Yes. > ...so different? Yes. > ...a confusion? Thats how it seems. >
I don't agree. 11.2.1: "The first from of define binds <variable> to a new location before assigning the value of <expression> to it." (other forms are trivially expressed using the first) That's exactly #1 (new location), #2 (setting the value) and #3 (binding of the new location to the given name). I can only relate #3 to the meaning of eqv? (the name) before (define eqv? ...). > > The way I read R6RS, (define) is supposed to (#1) allocate a new > > location for this new eqv?, (#2) set! the result of the expression > > to it and (#3) mutate the *binding* for eqv? in the environment (or > > splice into parent environment when enclosed by begin). At least, > > that's what it typically does for other variables. I.e., > > That's r5rs w/out any module system. Not r6rs (in a library). > Is there a difference? Let's see... 11.2: "Definitions may appear within a <top-level body> (section 8.1), at the top of a <library body> (section 7.1), or at the top of a <body> (section 11.3)." 8.1: "A <top-level body> is like a <library body> (see section 7.1), except that definitions and expressions may occur in any order." so => not this one, > > > And, BTW, 11.3 says that (define) is equivalent to (letrec*). So why > > are these cases so different then? > > Because those are internal definitions. Again, what's the difference? Let's see... 7.1: "A <library body> is like a <body> (see section 11.3) except that a <library body>s need not include any expressions." so => not this one either, Finally: 11.3: "An expanded <body> (see chapter 10) containing variable definitions can always be converted into an equivalent letrec* expression." Chapter 10 goes into fine details of how to reorder according to 8.1. > > > > I guess if R6RS enforced macro-implementation of (case), like > > Haskell's Prelude, the problem would be solved (via syntactic > > closures provided by hygiene & referential transparency of > > syntax-rules). > > ?? Let just prescribe the "wanted" syntax-rules implementation of case in the standard. Then there can be no confusion about its meaning and no PhD required to understand what the standard intends but does not say. _______________________________________________ r6rs-discuss mailing list r6rs-discuss@lists.r6rs.org http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss