velco has quit ["<boris``> reduction ad absurdum is a fallacious method of proof"]
Mr_Awesome has joined #ocaml
ludwig- has quit [Read error: 104 (Connection reset by peer)]
ludwig- has joined #ocaml
chi11 is now known as velco
love-pingoo has joined #ocaml
Submarine has joined #ocaml
ikaros has quit ["Leaving"]
ikaros has joined #ocaml
ikaros has quit [Client Quit]
david_koontz has joined #ocaml
dbueno has joined #ocaml
<dbueno>
How is it that "compare == compare;;" --> false
<dbueno>
(Toplevel, nothing special loaded.)
ikaros has joined #ocaml
ikaros has quit [Client Quit]
kasv has left #ocaml []
<stevan__>
dbueno: functions cannot be compared for equality
<stevan__>
dbueno: see the recent discussion on caml-list for the fine details
pango_ has quit [Remote closed the connection]
pango has joined #ocaml
<flux->
I think that's a different issue
<flux->
but physical equality is a funny thing..
<flux->
if you say let a = compare in a == a it yields true, however
<flux->
I tried to use physical equality into something useful but it's difficult to use
<flux->
the case was one where I have a global serial counter for events, and I want to take a snapshot of the counter and later compare if any events have occurred
<flux->
I thought I could just construct a () for the counter whenever it changes, and then compare for physical equality with the earlier snapshot, letting gc do the dirty work (and as an added bonus I wouldn't need to lock the serial with a mutex - it was a threaded app)
love-pingoo has quit ["Connection reset by pear"]
<flux->
but some difficulty occurred.. I don't remember the specifics though
<flux->
well, atleast unit values are physically the same, apparently
<flux->
empty strings aren't
<flux->
maybe I just messed up, perhaps I'll retry that approach again later :)
<flux->
(let new_tag () = String.copy "" is what I should've used instead of (iirc) let new_tag () = "", which leads into different tags being physically equal)
<dbueno>
Right. That makes sense.
<flux->
but the compare-thing is somewhat interesting. maybe you could ask from a mailing list..
<dbueno>
And I understand that, short of solving the Halting Problem, equality (=) is not likely to support functional values any time soon.
<dbueno>
But I don't understand why (==) wouldn't. I haven't looked at the caml-list yet, though.
<flux->
maybe it has got something to do with that compare isn't implemented in ocaml
<flux->
but rather refers to a c-function
<flux->
could be a bug
<dbueno>
I would think it would still "live" in one area. Maybe there is memory rearrangement for GC that leads to (==) being unreliable even in the case of functions.
<flux->
can == give false positives?
<flux->
could maybe gc merge objects together?
<flux->
if they are structurally equivalent
<flux->
false positives would be an issue for the use I was thinking, false negatives wouldn't
<flux->
but it would seem strange how it could ever give a false negative..
<dbueno>
For the use I was considering, false positives would be unacceptable, but false negatives fine (for correctness).
<flux->
actually, maybe it would be permissible to make copies of objects during the gc, and it might even make sense for some concurrent gc:s for that to occur..
ikaros has joined #ocaml
ikaros has quit [Client Quit]
ikaros has joined #ocaml
bluestorm has joined #ocaml
ikaros has quit ["Leaving"]
batdog|gone has quit ["changing servers"]
batdog|gone has joined #ocaml
benny has joined #ocaml
dbueno has quit ["Leaving"]
bluestorm has quit ["Konversation terminated!"]
benny_ has quit [Read error: 110 (Connection timed out)]
<pango>
I guess that for some reason 'compare' above is a closure
Alneyan has joined #ocaml
<pango>
mmh not sufficient... created a function f, f == f is true and f also has a closure tag