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@scheme-reports.org http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
