From: Jacques Carette <carette@mcmaster.ca>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] Re: Equality of functional values
Date: Wed, 31 Jan 2007 07:54:16 -0500 [thread overview]
Message-ID: <45C09178.8010204@mcmaster.ca> (raw)
In-Reply-To: <jwvd54vy96q.fsf-monnier+gmane.comp.lang.caml.inria@gnu.org>
The only times where I have used intensional equality (which was in a
dynamically typed system for doing mathematics), it would have
considered the bottom two lambda-expressions to be _different_, as in
SML/NJ.
This intensional equality is only used for optimizations. A function
can optimize some cases based on intensional equality with some known
cases, and fall-through to a slower general case otherwise. Not
recognizing two terms as equivalent only results in slower computation
time, not an incorrect result. You might see it as a sort of
overloading based on function-level matching.
Maple, Mathematica and MuPAD (internally) use this kind of
dispatch-on-function feature a lot. This is related to the issue that
in all these languages, 'constructors' and 'functions' are one and the
same. My experience is that in practice, this works. Perhaps it would
not be as useful in languages where constructors and functions are
different.
Jacques
Stefan Monnier wrote:
> I don't know what the OCaml optimizer may do, but I do know that in SML/NJ
> such an intentional equality would often not give the expected result,
> because it's pretty common for it to use various forms of eta-like
> expansions in the hope of doing uncurrying or argument flattening, so you
> may end up with
>
> f == f
>
> turned into
>
> (λx1.λx2.f(x1,x2)) == (λy1.λy2.f(y1,y2))
>
> and the system may not try to recognize that the two lambda-expressions are
> identical (too costly an analysis for no performance benefit), so it will
> compile them to two different pieces of machine language.
>
>
> Stefan
>
>
next prev parent reply other threads:[~2007-01-31 12:54 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-01-29 21:04 Simon Frost
2007-01-29 21:11 ` [Caml-list] " Tom
2007-01-29 21:23 ` Brian Hurt
2007-01-29 21:59 ` Gerd Stolpmann
2007-01-30 8:17 ` Christophe Raffalli
2007-01-30 8:45 ` David MENTRE
2007-01-30 13:24 ` Andrej Bauer
2007-01-30 13:55 ` skaller
2007-01-30 14:21 ` Brian Hurt
2007-01-30 15:21 ` Jeff Polakow
2007-01-30 15:49 ` Jacques Carette
2007-01-30 17:23 ` Chris King
2007-01-30 20:18 ` Tom
2007-01-30 20:30 ` Gerd Stolpmann
2007-01-30 20:41 ` Fernando Alegre
2007-01-30 21:01 ` Christophe TROESTLER
2007-01-30 21:08 ` Tom
2007-01-30 21:46 ` Christophe TROESTLER
2007-01-30 22:05 ` Fernando Alegre
2007-01-30 23:13 ` skaller
2007-01-30 23:06 ` Andrej Bauer
2007-01-31 0:15 ` Jacques Carette
2007-01-31 7:03 ` Stefan Monnier
2007-01-31 12:54 ` Jacques Carette [this message]
2007-01-31 0:15 ` [Caml-list] " skaller
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=45C09178.8010204@mcmaster.ca \
--to=carette@mcmaster.ca \
--cc=caml-list@inria.fr \
--cc=monnier@iro.umontreal.ca \
/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;
as well as URLs for NNTP newsgroup(s).