#lisp - Sat 24 Feb 2007 between 00:12 and 00:30

NY Lost Funds



lukegocoffee-mug: are you the proprietor of defmacro.org?
coffee-mugyeah
I am
interestingly I'm also a common lisp newbie :)
lukegonice site
coffee-mugthanks
beachcoffee-mug: did you read the article on equality by Kent Pitman?
lukego"Equality is hard" argument annoys me a bit as an Erlang programmer. hard to say why Erlang's == is so simple and predictable, the reasons are a bit subtle
hefnerwhat if == is simple because erlang is hard?
pkhuonglukego: is erlang purely functional (modulo single assignment vars)? That makes things `slightly' simpler.
beachlukego: it is not just about being simple and predictable.
oh, and good morning everyone.
coffee-mugbeach: yeah, I did
lukegopartly true. but for one nice example, in Erlang 'spawn' returns an opaque object called a process identifier (pid). it could just as easily have been called a "process" instead of a "process identifier" but one consequence of that is that it would make == more confusing since the semantics of == on process identifiers is obvious and intuitive
beachcoffee-mug: I didn't see any reference to it in your article.
coffee-mugbeach: yeah, I actually read Kent's article after I wrote that post
lukegoI am more annoyed by the Pitman article :) as a functional programmer it once more seems like creating a big mess and then saying "boy even simple things are really hard!" :)
beachcoffee-mug: ah, OK.
coffee-mugI had a few people email me links to various classic articles on equality
well, equality isn't really simple
it can be made simple
in Haskell for example it's made simple
but that also means that built in Haskell facilities have a limited notion if equality
beachlukego: I think he is right though that two objects can be equal in some context and not in some other. For instance, the phone company thinks me and my wife are equal because we have the same phone number. Our respective employers think we are different.
coffee-mugbeach: right, this is C++'s notion of "equivalence"
you define equivalence as necessary and pass it to containers
so it can be different in different cases
pkhuongcoffee-mug: or CL. see all the :test arguments.
coffee-mugI think of equality as I do of morality
lukegobeach: true, I know what you mean. but it seems like there are two ways to handle that: at the "application level" or with deep indirections and hooks into lower levels (e.g. generic functions). i'm fundamentally in favour of simple & predictable building blocks to work from.
coffee-mugis there a unified global notion of morality?
most people tend to say yes, but the minute you dig a little deeper you realize that it isn't so simple
equality is the same way
lukego: ok, but in a deeply nested structure do you compare pointers or data itself?
lukego: if you choose to compare data itself it'll be inpractical, especially if the structures are large
pkhuongcoffee-mug: in a purely functional language, comparing pointers for eq-ness is strictly an optimisation.
lukegobeach: for example if I want to check if two telephone-subscriber structures have the same #phone-number slot I have no greate desire to make (EQUAL TS1 TS2) the way to do that
coffee-mugif you choose pointers you'll break the mathematical model
lukegocoffee: I like how Erlang does it. :)
coffee-mugpkhuong: right, that's the Haskell way

Page: 2 9 16 23 30 37 

IrcArchive

NY Lost Funds