On Fri, Mar 30, 2012 at 17:28, Yaron Minsky <ymi...@janestreet.com> wrote: > Hrm. The polymorphic equality thing makes me a little sick --- we're > actually trying to avoid polymorphic compare wherever we can these > days, for both performance and semantic reasons. Is there a reason it > can't use comparison of s-expressions? I don't think efficiency is a > primary concern here, since this is already fairly slow > pretty-printing code.
I guess nobody is fully satisfied with polymorphic equality in general. I'm not sure there is any true gain in comparing S-expressions. One could imagine that some S-expression converters normalize the representation so that e.g. sets, maps, etc., would compare consistently, but this is not a given (e.g. hashtables). Furthermore, in the vast majority of cases we would needlessly convert a value to an S-expression just for equality checking even though it need not be emitted in the first place - a rather expensive default behavior.
The only consistent solution I can see is if the user can optionally specify an equivalence relation, e.g. by having another optional expression that contains such a function. But this could turn out to be extremely expensive: think of comparing hashtables.
Default field values are probably hardly ever changed back and forth at runtime, especially in ways that would destroy pointer equality or worse to a structurally distinct but semantically equivalent representation. Polymorphic equality checks would therefore almost always just compare two identical pointers anyway, which is both consistent and maximally efficient. Even if a field were emitted that need not be, this should never cause any issues other than diminished output readability.
I'd therefore suggest to use polymorphic equality for the while being. If it really turns out to cause issues in practice, you can always add the mentioned optional equality function later.