From: Ethan Burns <burns.ethan@gmail.com>
To: fa.caml@googlegroups.com
Cc: Dmitry Bely <dmitry.bely@gmail.com>, caml-list@inria.fr
Subject: Re: [Caml-list] Comparing variant types
Date: Fri, 29 Apr 2011 04:54:17 -0700 (PDT) [thread overview]
Message-ID: <b65f0631-fab3-48ca-ac6b-5bc59b32b5d5@glegroupsg2000goo.googlegroups.com> (raw)
In-Reply-To: <fa.FGXk5PCsQgS8TidmFkgljpqbLZo@ifi.uio.no>
On Friday, April 29, 2011 5:34:16 AM UTC-4, luc.ma...@inria.fr wrote:
> As a general rule, don't do that! :) (using <> or !=
> for writing 'g').
>
>
> For <>, you'll get hurt by data types with non-unique representation
> (such as Set), as already pointed out.
> It is ok to use structural equality when it is not the case, but
> your programm is not as robust as you may want it to be.
Well, in this case I am actually not really writing the function g and instead this comparison is embedded in another function somewhere. My feeling was that using <> would be perfectly safe because it would translate to an integer comparison. The structure of a type containing only simple constructors should be unique (I think they are all just mapped to ints).
> For !=, it is much worse, as soon as you add a non-constant
> constructor to your data type, your code is wrong
> (cf. [1] != [1])
>
> If you aim at robust code. A recommended (tiresome) alternative
> is to write your own equality function once for all, in
> the following style.
>
> type dir = Left | Right | Up | Down | No_op
>
> let dir_equal d1 d2 = match d1,d2 with
> | (Left, Left)
> | (Right,Right)
> | (Up, Up)
> | (Down,Down)
> | (No_op,No_op)
> -> true
> | (Left,(Right|Up|Down|No_op))
> | (Right,(Left|Up|Down|No_op))
> | (Up,(Left|Right|Down|No_op))
> | (Down,(Left|Right|Up|No_op))
> | (No_op,(Down|Up|Right|Left))
> -> false
This is tiresome indeed! Also, I am concerned that it is less efficient than just dropping down to compare_val (although I haven't tried it). Since the type that I am using will only ever have a unique representation, I would love to avoid something like this.
I think that the solution that I will stick with for now is the one given by Dmitry (although I am typically not a fan of != in general). Fabrice seemed to imply that optimizing <> in this case was 'in the works.' I will be pretty happy to see that because I am sure that I have other code lying around somewhere that is assuming <> on a simple 'enum type' is just an integer comparison.
Best,
Ethan
next parent reply other threads:[~2011-04-29 11:54 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <fa.FGXk5PCsQgS8TidmFkgljpqbLZo@ifi.uio.no>
2011-04-29 11:54 ` Ethan Burns [this message]
2011-04-28 19:16 Ethan Burns
2011-04-28 21:07 ` Vincent Aravantinos
2011-04-28 22:56 ` Ethan Burns
[not found] ` <354087020.772283.1304031467793.JavaMail.root@zmbs4.inria.fr>
2011-04-29 8:46 ` Fabrice Le Fessant
2011-04-29 8:57 ` Dmitry Bely
[not found] ` <164004794.892685.1304067487325.JavaMail.root@zmbs2.inria.fr>
2011-04-29 9:33 ` luc.maranget
2011-04-29 10:54 ` Andrew
2011-04-29 11:17 ` Dmitry Bely
2011-04-29 12:15 ` Jon Harrop
2011-04-30 16:38 ` Andrew
2011-04-29 11:32 ` Dmitry Bely
2011-04-30 13:43 ` craff73
2011-04-30 19:26 ` Andrew
2011-04-30 20:19 ` Gabriel Scherer
2011-04-30 20:57 ` Yaron Minsky
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b65f0631-fab3-48ca-ac6b-5bc59b32b5d5@glegroupsg2000goo.googlegroups.com \
--to=burns.ethan@gmail.com \
--cc=caml-list@inria.fr \
--cc=dmitry.bely@gmail.com \
--cc=fa.caml@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox