Google Groups

Re: sexp_default


Markus Mar 30, 2012 3:09 PM
Posted in group: ocaml-core
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.

--
Markus Mottl        http://www.ocaml.info        markus...@gmail.com