From: Jon Harrop <jdh30@cam.ac.uk>
To: caml-list@inria.fr
Subject: Re: [Caml-list] Functors
Date: Thu, 6 May 2004 12:16:53 +0100 [thread overview]
Message-ID: <200405061216.53738.jdh30@cam.ac.uk> (raw)
In-Reply-To: <Pine.LNX.4.58.0405051257110.15595@grace.speakeasy.net>
On Wednesday 05 May 2004 21:41, brogoff@speakeasy.net wrote:
> I'm not sure I understand the difference, since there is only one
> defunctorizer for OCaml, wouldn't including it in the compiler be the
> easiest way to get that functionality?
As someone else said, using a "defunctorizer" apparently makes it impossible
to perform some static analysis. Obviously, static analysis is a strong point
of the language so we definitely want to keep that. I think this is an
example of the static analysis being broken: use the core library Set functor
to create a module implementing a set of integers, create two sets and merge
them. If this were functorised, the integer compare could be inlined (which
would probably result in a significant performance boost) but it would no
longer be possible to statically check that the two sets being merged shared
a common comparison function (which could be done statically before provided
they were both created by our "integer set" module) because you can't compare
functions.
So you don't want to just plug the defunctorizer into the compiler. I was
suggesting the application of much lower-level code transformations (at
intermediate- or assembler-representations) when possible, to in-line small
functions slightly more aggressively. I think this would be very useful,
probably quite easy to implement and I can't think of any downsides.
> ...
I would have thought that a bytecode->C compiler would be quite feasible and,
perhaps, quite useful. What other compilers for ocaml are there?
Cheers,
Jon.
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
next prev parent reply other threads:[~2004-05-06 11:17 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-05-02 9:12 Jon Harrop
2004-05-02 10:24 ` Martin Jambon
2004-05-02 13:34 ` Jon Harrop
2004-05-02 14:12 ` skaller
2004-05-02 16:49 ` Jon Harrop
2004-05-03 0:20 ` skaller
2004-05-03 14:43 ` Jacques Carette
2004-05-03 16:09 ` Alain.Frisch
2004-05-03 18:53 ` Jacques Carette
2004-05-03 19:17 ` [Caml-list] Mathematica Jon Harrop
2004-05-03 22:51 ` [Caml-list] Functors Alain.Frisch
2004-05-03 16:02 ` Julien Signoles
2004-05-03 18:41 ` Jon Harrop
2004-05-04 7:25 ` Jean-Christophe Filliatre
2004-05-05 8:15 ` Julien Signoles
2004-05-05 20:41 ` brogoff
2004-05-06 11:16 ` Jon Harrop [this message]
2004-05-06 20:23 ` Alain.Frisch
2004-05-06 18:26 ` Olivier Grisel
2004-05-06 12:26 ` Julien Signoles
2004-05-06 16:35 ` brogoff
2004-05-02 17:18 ` David Brown
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=200405061216.53738.jdh30@cam.ac.uk \
--to=jdh30@cam.ac.uk \
--cc=caml-list@inria.fr \
/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