[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Scheme-reports] [r6rs-discuss] redefining eqv?
On Fri, 2010-12-24 at 11:00 -0500, Eli Barzilay wrote:
> *sigh*... This is a frustrating mis-discussion. I said above that
> you're confusing the two things, to which you replied with an obscure
> "is it", so I answered three possible interpretation of that -- and
> you continue with the vagueness: if you want to discuss something then
> plase be more specific about what is it that you don't agree with.
>
And there we agree again ;-)
> > 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 location that the text refers to is due to mutable variables in
> Scheme. It means that bindings map identifiers too (mutable)
> locations rather than to values (which makes them all constant, as in
> other functional languages like ML). None of this happens when you
> *re*define a binding -- that case turns into an implicit assignment in
> R5RS (sans modules)
Any pointers to where this is specified? If a re-definition is the
same as assignment, then why this yields 1 (in all R5RS implementations
I know)
(define x 1)
(let () (define x 2) x)
x
> but it is not intended to be a device that you'd
> use instead of assignment, only as a way to reload code and getting
> new values in effect for existing references. It also doesn't happen
> in R6RS where you just don't redefine bindings.
I probably should stop this thread now, its getting nowhere...
> > > That's r5rs w/out any module system. Not r6rs (in a library).
> >
> > Is there a difference? Let's see...
>
> Yes, there is a difference. A toplevel `define' in R5RS is analogous
> to a side-effect in a single ongoing repl, and in R6RS it is more like
> an internal define, scoped by the library it is part of.
>
Again, where is the reference?
> > 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,
>
> (I have no idea what that "=>" stads for, what "this" refers to, and
> what "not" negates.)
I was looking here for any justification of your statement about the
difference between REPL/top-level-define and library-define
in the standard. AFAICS the standard prescribes them to be the same
modulo ordering of uses and respective definitions of variables.
> > Again, what's the difference?
>
> An internal block of `define's is equivalent to a `letrec' (or a
> `letrec*' in R6RS), for example, this:
>
> (define x 1)
> (define x 2)
>
> cannot appear in an internal definition context in the same way that
> you cannot have two bindings for `x' in a `letrec'. This behavior
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> makes these kinds of definitions very different than the kinds of
> mutations you are trying to promote (the toplevel redefinition of
> `eqv?')
You mean, you can't re-define eqv? All Scheme implementations that I
tried, and including Scheme-like ones (like Racket) do allow it (except
Ikarus).
>
>
> > 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,
>
> (Still no clue why you quoted that, or what the conclusion is supposed
> to be.)
Again, I was looking for justifications of library-define being
different from regular define in the standard, and this could not have
been the one.
>
>
> > 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.
>
> (Or why the ordering of definitions is relevant.)
Its not, as I concluded above.
> (So far I see only one person who was confused over that.)
Probably because everybody else have participated in the process
that resulted in R6RS.
>
> It's the nth time that you ask to specify that `case' be implemented
> as a macro -- yet you haven't provided any motivation for doing so.
Note that its not me that started with macro-definition of case. I do
find it much more acceptable though than the vague definition found in
the R6RS. Or say explicitly like Andre van Tonder:
"No, because CASE refers to the original (immutable and unmutated)
slot of EQV"
>
> The only thing that looks close to a reason is your desire to be able
> to customize the equality that it uses -- yet this doesn't require
> forcing a macro implementation. For example, the text could replace
>
> in the sense of `eqv?'
>
> with
>
> in the sense of the current lexical binding for `eqv?'
>
> and you get your kind of customization hook without a requirement on
> the implementation.
>
That's also acceptable.
> As for the hook itself, there is first the question of why a hook is
> needed, and then there's how it should be implemented. The solution
> of mutating `eqv?' is pretty horrible IMO -- and it's worse when you
> actually want to do this by a `define'. If anything, you should go
> with advocating a plain `set!' which would clarify that you really
> want some more "hook-ish" name like `current-equality', and better to
> use some feature that avoids race conditions for threaded
> implementations (eg, racket parameters).
I am not in favor of set!, by all means. But still maintain that set!
is very different from define.
>
> That would be a much better suggestion, which I still won't like
> because of situations like:
...
> or (b) I write my `bar' in a defensive way and make sure that
> `current-equality' is set to `eqv?', ending with similar hair.
>
> Both of these seem much more unpleasant than passing in the equality
> as an additional argument to some `case-with'.
No problem there, lets do that (if veterans agree).
_______________________________________________
Scheme-reports mailing list
Scheme-reports@x
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports