From: Jeremy Bem <jeremy1@gmail.com>
To: Jon Harrop <jonathandeanharrop@googlemail.com>
Cc: bluestorm <bluestorm.dylc@gmail.com>,
caml-list List <caml-list@yquem.inria.fr>,
Florian Weimer <fw@deneb.enyo.de>
Subject: Re: [Caml-list] interest in a much simpler, but modern, Caml?
Date: Wed, 11 Aug 2010 20:21:43 -0400 [thread overview]
Message-ID: <AANLkTi=Gcy2eBcQ2peOawnUk2Qfq1uOXSdSAouAnS=Hj@mail.gmail.com> (raw)
In-Reply-To: <03fb01cb3955$76093770$621ba650$@com>
[-- Attachment #1: Type: text/plain, Size: 2325 bytes --]
On Wed, Aug 11, 2010 at 9:02 AM, Jon Harrop <
jonathandeanharrop@googlemail.com> wrote:
>
> What happens when you do:
>
> if Int.(x = 42 || x = 45) then ... else ...
>
> Presumably it either barfs on the assumption that "||" refers to bitwise-or
> between ints, or we're back to inventing progressively more absurd operator
> names for each individual combination of types over which they might work.
>
How so? I think this is a borderline case (even in C++, "||" does not refer
to bitwise-or). But even if Int.(||) *were* defined as some sort of integer
operation, one could simply write:
if Int.(x = 42) || Int.(x = 45)
Also, I think the discussion has shifted. For me, the local open is a
reasonably appealing way to stop using OCaml's exotic polymorphic operators
whose behavior depends on the runtime representation and which don't respect
type abstraction. (For example, ocamllex uses Pervasives.(=) to test
whether Map's are empty, but this breaks if the Map representation changes.)
Moreover the syntax even maintains OCaml compatibility thanks to the recent
update. But now we seem to be talking about operator overloading, and I'm
just not convinced it's necessary at all in a system with a minimalist
aesthetic.
Back to the local opens, I find that I'm hesitant to add so many of them,
especially for equality. Polymorphic equality is hardly unnatural, after
all (cf. higher-order logic). I wonder, do any practical languages use
quotient types to implement custom equality predicates? In principle,
Pervasives.(=) ought to be the "finest" reasonable equivalence relation on a
type, which could then be coarsened:
type foo = Foo of int | Goo of string
let _ = assert (Foo 3 <> Goo "3") (* duh *)
let foo_equiv x y =
match x, y with
Foo a, Foo b -> a=b
| Goo a, Goo b -> a=b
| Foo a, Goo b
| Goo b, Foo a -> string_of_int a = b
type goo = foo / foo_equiv (* automatically creates goo_of_foo *)
let _ = assert (goo_of_foo (Foo 3) = goo_of_foo (Goo "3"))
This would require runtime support. I envision that every "goo" is a block
whose tag is "Quotient_tag" and which stores a "foo_equiv" closure in its
first Obj field.
As it happens, this approach would dovetail with my plans for an integrated
proof assistant. Of course it lacks the "conservatism" I've been promoting
:)
-Jeremy
[-- Attachment #2: Type: text/html, Size: 3827 bytes --]
next prev parent reply other threads:[~2010-08-12 0:21 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-06 4:04 Jeremy Bem
2010-08-06 13:50 ` [Caml-list] " Eray Ozkural
2010-08-08 17:59 ` Florian Weimer
2010-08-08 18:44 ` Jeremy Bem
2010-08-08 18:52 ` Florian Weimer
2010-08-08 19:39 ` Jeremy Bem
2010-08-09 11:55 ` Nicolas Pouillard
2010-08-11 13:00 ` Jon Harrop
2010-08-08 20:53 ` Nicolas Pouillard
2010-08-08 20:59 ` Jeremy Bem
2010-08-08 21:47 ` bluestorm
2010-08-08 23:00 ` Christophe TROESTLER
2010-08-08 23:29 ` Jeremy Bem
2010-08-11 13:02 ` Jon Harrop
2010-08-12 0:21 ` Jeremy Bem [this message]
2010-08-12 23:14 ` Jon Harrop
2010-08-09 13:10 ` David House
2010-08-09 14:03 ` Nicolas Pouillard
2010-08-08 20:52 ` Nicolas Pouillard
2010-08-11 12:56 ` Jon Harrop
2010-08-09 6:37 ivan chollet
2010-08-09 10:54 ` Cedric Cellier
2010-08-09 15:00 ` ivan chollet
2010-08-09 15:03 ` ivan chollet
2010-08-11 13:19 ` Jon Harrop
2010-08-11 16:12 ` philippe
2010-08-12 6:56 ` ivan chollet
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='AANLkTi=Gcy2eBcQ2peOawnUk2Qfq1uOXSdSAouAnS=Hj@mail.gmail.com' \
--to=jeremy1@gmail.com \
--cc=bluestorm.dylc@gmail.com \
--cc=caml-list@yquem.inria.fr \
--cc=fw@deneb.enyo.de \
--cc=jonathandeanharrop@googlemail.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