On Thu, 2005-02-24 at 10:29 -0500, Sandro Magi wrote: > This does seem to capture the two distinct "equality" flavours I've > encountered. However, I'd be inclined to drop the over-used "equal" > terminology entirely and adopt more descriptive names: > > equiv? equivalence, ie. (recursive) structural equality > > ident? identity equality (or perhaps ref-eq? or ref-equiv?)
I see what you mean. For better or worse, equal? and eq? have a long tradition, and I'm not going to change that. > > Consider implementation of a set of objects or a generic collection. In > > order to implement fast membership checks and a fast union operation, > > every object must have not just an equality check, but a magnitude > > check. If we want fast, generic collection implementations, we somehow > > need to address this, and it would be really nice NOT to pass a function > > pointer to a type-specific magnitude comparator function. > > > Theoretically, the size only needs to be extracted once for each typed > collection, doesn't it? It's not so bad if that's the case. I am not clear why size is an issue at all. The issue is comparison with less-than? and greater-than? > So if I'm understanding the collections issue correctly, the problem is > that you want one operator that can be used to check > equality/identity/equivalence over both value types and reference types... That isn't hard to do. The problem is that we need to do magnitude comparisons in order to avoid very expensive set operations. > Isn't the magnitude of a reference type simply the magnitude of the > pointer? The pointer is what is used in constructing types after all, so > its contribution to the size of the constructed type is the size of the > pointer. Not in the case where the garbage collector may result in a heap where the objects have been reordered in memory. > Perhaps I'm just misunderstanding the use cases. How were you thinking > these generic collections would store their values? Would each item be > "boxed", or would each item be copied by value and held internally? Boxing vs. unboxing isn't the problem. shap _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
