2 ms·

That will be terribly inefficient for asserting inequality of large objects.

kazinator 10y ago
So: don't write huge objects---it's a code smelly anti-pattern anyway; or don't make every single member of a large object participate in equality; or else, cache the equality substitution and re-compute it if the object is modified. I'm adding a dirty flag to the object system in the next release. If any slot is modified, the object will be marked dirty; an API will be provided for testing and clearing the dirty flag. This will make it a cinch to write the above point class so that it returns the same list if the object is clean. Also, when the object is dirty and the representative list must be recomputed, the cons cells of the old list can be re-used; we don't have to allocate a new list. Most of the time, you don't want that anyway; objects should be immutable as much as possible. If you have objects in a hash table, you don't want to fiddle with them in ways that affect their equality. Speaking of which, this is one of the ways in which the equality substitution is used in real code. Certain slots of the objects are treated as immutable and the equality substitution is based on those slots. The objects are put into hash tables based on that equality. Yet they have other slots treated as mutable. Those don't count toward equality. If they did, the hashing would be in trouble, obviously.
- jstimpfle 10y ago
  > So: don't write huge objects---it's a code smelly anti-pattern anyway I tend to agree. But even for structures of only say, 4, primitives, it's still faster to only compare two primitives in the common case, instead of hashing 8 and comparing two hashes. In the same way it could also be argued that needing hash functions for testing equality is a code smell. Equality makes only sense for small clean data structures of primitives. Equality for those should be inferred from the compiler by the primitives' equalities. Also, how can hash collisions be avoided?
deleted 10y ago
[deleted]

So: don't write huge objects---it's a code smelly anti-pattern anyway; or don't make every single member of a large object participate in equality; or else, cache the equality substitution and re-compute it if the object is modified. I'm adding a dirty flag to the object system in the next release. If any slot is modified, the object will be marked dirty; an API will be provided for testing and clearing the dirty flag. This will make it a cinch to write the above point class so that it returns the same list if the object is clean. Also, when the object is dirty and the representative list must be recomputed, the cons cells of the old list can be re-used; we don't have to allocate a new list. Most of the time, you don't want that anyway; objects should be immutable as much as possible. If you have objects in a hash table, you don't want to fiddle with them in ways that affect their equality. Speaking of which, this is one of the ways in which the equality substitution is used in real code. Certain slots of the objects are treated as immutable and the equality substitution is based on those slots. The objects are put into hash tables based on that equality. Yet they have other slots treated as mutable. Those don't count toward equality. If they did, the hashing would be in trouble, obviously.

jstimpfle 10y ago
> So: don't write huge objects---it's a code smelly anti-pattern anyway I tend to agree. But even for structures of only say, 4, primitives, it's still faster to only compare two primitives in the common case, instead of hashing 8 and comparing two hashes. In the same way it could also be argued that needing hash functions for testing equality is a code smell. Equality makes only sense for small clean data structures of primitives. Equality for those should be inferred from the compiler by the primitives' equalities. Also, how can hash collisions be avoided?

deleted 10y ago

[deleted]