[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Scheme-reports] [r6rs-discuss] redefining eqv?
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>
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?
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,
11.3: "An expanded <body> (see chapter 10) containing variable
definitions can always be converted into an equivalent letrec*
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.
Scheme-reports mailing list