Re: RTL Question
On Tue 19 Jun 2012 05:52, Noah Lavine noah.b.lav...@gmail.com writes: Time for my next RTL question - how do I use the toplevel-ref instruction? It looks like I need to make a variable object in the instruction stream, or at a known offset from it. I think I should use either make-non-immediate or the linker to do that, but I don't quite know how. I haven't yet wired that up. You have it right: a variable object in the object file. It's not actually in the instruction stream: it's in another section. The other section will be writable and end up on a different page in memory, so that we share the text but not the writable data. Also the writable data section will be added as a GC root. I think the thing to do is to add a macro-instruction that emits a toplevel ref, adds a variable object to the constant table, and adds a relocation so that the offset is fixed up at link time. Another option would be to implement inline caches for toplevel references, and also toplevel calls. A reference would be a thunk call. The first reference would update the cache. You could share the caches for accesses to the same toplevel within a function. They have to be very few (bytecode) instructions in the hot case though, otherwise that would be a lose. Dunno. That part is still unsettled, basically! Andy -- http://wingolog.org/
Bug in documentation for eq? ?
I read Numbers and characters are not equal to any other object, but the problem is they're not necessarily `eq?' to themselves either. This is even so when the number comes directly from a variable, (let ((n (+ 2 3))) (eq? n n)) = *unspecified* I think that is wrong. A variable reference can't really be anything except eq? to itself in my opinion. As long as a Scheme object is not being manipulated in any manner, it should stay eq? to itself. What am I missing? -- David Kastrup
Re: Bug in documentation for eq? ?
On Wed 20 Jun 2012 12:40, David Kastrup d...@gnu.org writes: Numbers and characters are not equal to any other object, but the problem is they're not necessarily `eq?' to themselves either. This is even so when the number comes directly from a variable, (let ((n (+ 2 3))) (eq? n n)) = *unspecified* Note that this example is taken from R5RS section 6.1. A variable reference can't really be anything except eq? to itself in my opinion. Depends on inlining. Numbers are not considered to have identity, so they may be copied in some situations. Therefore that expression is equivalent to (eq? (+ 2 3) (+ 2 3)) which is unspecified. In summary, I think the documentation is correct. Regards, Andy -- http://wingolog.org/
Re: Bug in documentation for eq? ?
Andy Wingo wi...@pobox.com writes: On Wed 20 Jun 2012 12:40, David Kastrup d...@gnu.org writes: Numbers and characters are not equal to any other object, but the problem is they're not necessarily `eq?' to themselves either. This is even so when the number comes directly from a variable, (let ((n (+ 2 3))) (eq? n n)) = *unspecified* Note that this example is taken from R5RS section 6.1. A variable reference can't really be anything except eq? to itself in my opinion. Depends on inlining. Numbers are not considered to have identity, so they may be copied in some situations. I can't see this being such a situation. The number 5 as such does not have identity. But each individual instance of the number 5 is a Scheme object, and Scheme objects have identity. That different instances of 5 may or may not compare eq?: no question about that. But the same? That's just silly. In summary, I think the documentation is correct. I think it is completely absurd. It would mean, for example, that (memq x (list x)) is generally unspecified. It would mean that things like (eq? (car x) (car x)) are generally unspecified even when x is a pair. We have scheme@(guile-user) (eq? +nan.0 +nan.0) $8 = #f scheme@(guile-user) (eqv? +nan.0 +nan.0) $9 = #t scheme@(guile-user) (= +nan.0 +nan.0) $10 = #f scheme@(guile-user) (let ((x +nan.0)) (eq? x x)) $11 = #t scheme@(guile-user) (let ((x +nan.0)) (eqv? x x)) $12 = #t scheme@(guile-user) (let ((x +nan.0)) (= x x)) $13 = #f And that makes sense since eqv? is supposed to apply to a superset of eq? while = is working on numerical values. Which of the above would you consider unspecified? -- David Kastrup
Re: Bug in documentation for eq? ?
David Kastrup d...@gnu.org writes: I think it is completely absurd. It would mean, for example, that (memq x (list x)) is generally unspecified. It would mean that things like (eq? (car x) (car x)) are generally unspecified even when x is a pair. So that we can have (eq? x x) but not (eq? (car x) (car x)). I really don't care what the standard claims. That a Scheme object should be able to become un-eq? to itself just because it is a number is nonsense. That different number expressions might or might not end up as one object because of a lack of identity is fine. But that a Scheme object might split into several un-eq? identities is schizophrenic. That would violate more invariants than anything. It is fine if the optimizer decides not tracking the identity of numbers. But that means that, absent any reliable identity information, it must declare equal numbers as eq?, not as un-eq?. This is a one-way street. Other options don't make sense. -- David Kastrup
Re: Bug in documentation for eq? ?
Hi, [bunch of examples] Which of the above would you consider unspecified? As the Scheme standard clearly states, all the ones comparing numbers with eq?. You find some of them surprising; that is your problem ;) The answer is to not compare numbers with eq?. Regards, Andy -- http://wingolog.org/
Re: bug#10410: guile: uri module confused by domain names starting with numbers, ipv6 addresses
Hi Daniel, Daniel Hartwig mand...@gmail.com skribis: I have noticed that the (web uri) module does not handle domain names that start with numbers: scheme@(guile-user) (string-uri http://123.com;) $1 = #f This one was fixed around commit 1868309a9e34a04a5b3020e147d0ce029038b290. Thanks, Ludo’.
Re: Bug in documentation for eq? ?
Hello, I think you're talking past each other a little bit. Andy is saying that the Scheme standard doesn't specify eq? on numbers. David is saying that an object should always be eq? to itself, no matter what object. I believe David's claim is that Guile should guarantee that a variable is eq? to itself, even though the standard doesn't. I don't know what the right answer is, but I think that's what this discussion should be about. Noah On Wed, Jun 20, 2012 at 9:17 AM, Andy Wingo wi...@pobox.com wrote: Hi, [bunch of examples] Which of the above would you consider unspecified? As the Scheme standard clearly states, all the ones comparing numbers with eq?. You find some of them surprising; that is your problem ;) The answer is to not compare numbers with eq?. Regards, Andy -- http://wingolog.org/
Re: Bug in documentation for eq? ?
On Wed 20 Jun 2012 15:41, Noah Lavine noah.b.lav...@gmail.com writes: I believe David's claim is that Guile should guarantee that a variable is eq? to itself, even though the standard doesn't. We could guarantee this, but it would prevent a number of interesting and permissible optimizations, for questionable semantic value. You should not consider variables as having identity, only values. Numbers do not have identity, so Guile can do with them as it pleases. Andy -- http://wingolog.org/
Re: Bug in documentation for eq? ?
Andy Wingo wi...@pobox.com writes: Hi, [bunch of examples] Which of the above would you consider unspecified? As the Scheme standard clearly states, all the ones comparing numbers with eq?. You find some of them surprising; that is your problem ;) The answer is to not compare numbers with eq?. You are confused. I am not comparing numbers when writing (eq? x x). I am checking the identity of an object. Whether that object is a number or not, and if so, what value it has, is irrelevant. If the Scheme standard states that (and (pair? x) (not (eq? (car x) (car x can return #t in a conforming implementation, that means that the standard failed to do its job for weeding out implementations with unusable behavior. But that does not mean that a given implementation should consider unusability to be a worthwhile goal. Cf. URL:http://www.gnu.org/prep/standards/standards.html#Non_002dGNU-Standards I would consider it an extremely bad idea if Guile (or for that matter, any other Scheme implementation) would ever produce anything but #t for (eq? v v) regardless of what v has been bound to. And I see no point in threatening the user that it might do so in an alternate universe. Again: it is fine if an optimizer chooses not to track object identities for numeric values. But if it doesn't, it needs to assume they are eq? when equal rather than some random choice. -- David Kastrup
Re: Bug in documentation for eq? ?
Andy Wingo wi...@pobox.com writes: On Wed 20 Jun 2012 15:41, Noah Lavine noah.b.lav...@gmail.com writes: I believe David's claim is that Guile should guarantee that a variable is eq? to itself, even though the standard doesn't. We could guarantee this, but it would prevent a number of interesting and permissible optimizations, for questionable semantic value. Name one. You should not consider variables as having identity, only values. Numbers do not have identity, so Guile can do with them as it pleases. Let's throw an error whenever using eq? on a number or running memq on a list containing a number. That would be interesting and apparently permissible behavior. I have my doubts that users will be impressed favorably. -- David Kastrup
Re: Bug in documentation for eq? ?
On Wed 20 Jun 2012 16:31, David Kastrup d...@gnu.org writes: Andy Wingo wi...@pobox.com writes: interesting and permissible optimizations Name one. FWIW, eta-conversion (for primitives). Copy propagation for the purposes of inlining (a la Waddell). Storing numbers in unboxed form, and only reifying a Scheme value when they need to leave a procedure. Andy -- http://wingolog.org/
Re: Bug in documentation for eq? ?
On Wed, Jun 20, 2012 at 4:27 PM, David Kastrup d...@gnu.org wrote: Andy Wingo wi...@pobox.com writes: If the Scheme standard states that (and (pair? x) (not (eq? (car x) (car x can return #t in a conforming implementation, that means that the standard failed to do its job for weeding out implementations with unusable behavior. The standard did its job by defining eqv? Do a (define eq? eqv?) at the start of your programs and you have what you are asking for.
Re: Bug in documentation for eq? ?
Andy Wingo wi...@pobox.com writes: On Wed 20 Jun 2012 16:31, David Kastrup d...@gnu.org writes: Andy Wingo wi...@pobox.com writes: interesting and permissible optimizations Name one. FWIW, eta-conversion (for primitives). Copy propagation for the purposes of inlining (a la Waddell). Storing numbers in unboxed form, and only reifying a Scheme value when they need to leave a procedure. How do you create un-eq? values from the same variable here? -- David Kastrup
Re: Bug in documentation for eq? ?
Andy Wingo wi...@pobox.com writes: On Wed 20 Jun 2012 16:27, David Kastrup d...@gnu.org writes: I am not comparing numbers when writing (eq? x x). I am checking the identity of an object. Whether that object is a number or not, and if so, what value it has, is irrelevant. x is not an object: it is a variable. Variables do not have identity. Variables have values. Values are scheme objects. Scheme objects have identity. Numbers of identical numeric value may or may not be mapped to identical scheme objects. But identical scheme objects may not choose to become unidentical. Something like (while (and (list? x) (pair? x)) (set! x (delq (car x) x))) should be guaranteed to terminate in any sane implementation, even if the list contains numbers. Whatever. It is quite clear that you can't be bothered with caring about sane semantics when the standard gives you a free pass. Forget I asked. I don't see the point in further serving as a target for pseudointellectual mockery. -- David Kastrup
Re: Bug in documentation for eq? ?
Pierpaolo Bernardi olopie...@gmail.com writes: On Wed, Jun 20, 2012 at 4:27 PM, David Kastrup d...@gnu.org wrote: Andy Wingo wi...@pobox.com writes: If the Scheme standard states that (and (pair? x) (not (eq? (car x) (car x can return #t in a conforming implementation, that means that the standard failed to do its job for weeding out implementations with unusable behavior. The standard did its job by defining eqv? Do a (define eq? eqv?) at the start of your programs and you have what you are asking for. Except efficiency. It appears you are confused about what I am asking for. I am perfectly fine with the possibility (eq? 0 0) = #f I am not fine with the possibility (eq? (car x) (car x)) = #f But it is clear that there is no interest in providing sane invariants for Guile programmers, so we can just quit this absurdity. -- David Kastrup
Re: Bug in documentation for eq? ?
On Wed 20 Jun 2012 17:16, David Kastrup d...@gnu.org writes: Whatever. It is quite clear that you can't be bothered with caring about sane semantics when the standard gives you a free pass. Forget I asked. I don't see the point in further serving as a target for pseudointellectual mockery. I am sorry to have to say this, but please do not post to this list any more. Thank you in advance. Andy -- http://wingolog.org/
