From: "Jacques Carette" <carette@mcmaster.ca>
To: Damien Doligez <damien.doligez@inria.fr>,
"'caml users'" <caml-list@inria.fr>
Subject: Re: [Caml-list] Single-case union types as strong typedefs
Date: Tue, 26 Oct 2004 11:05:26 -0400 [thread overview]
Message-ID: <web-70171963@cgpsrv2.cis.mcmaster.ca> (raw)
In-Reply-To: <67E54EEE-2758-11D9-BCF8-00039310CAE8@inria.fr>
Good points, which I will comment on in opposite order:
Damien Doligez <damien.doligez@inria.fr> wrote:
> On Oct 25, 2004, at 16:25, Jacques Carette wrote:
> > Yes, I am assuming that a fair bit of partial evaluation is a good
> > thing for
> > the compiler to do.
>
> Unfortunately, the compiler doesn't have all the information about the
> program. A lot of things are not known until link-time.
I consider a linker to be an integral part of a compiler 'suite'. I could not care less when a particular code
optimization is done. If it *has* to be done by the linker, then so be it. I do not understand why link-time
optimizations seem to have been somehow less research-worthy than other parts of the compiler.
> > Isn't that correct though? The value x is completely known
> > statically, and
> > all computation on x can be done statically, so it is not necessary to
> > have any traces of x left at run-time.
>
> Then how do you pass it to a polymorphic function?
And then what? What could that polymorphic function do with that value (without using Obj)?
In a system which insists on separate compilation, there is indeed a problem, and this ideal cannot be achieved. I
should have been clearer about the fact that I knew this.
Personally, I do not use separate compilation at "production" time anymore, only at development/debugging time. When
it comes time to produce a final executable, I use a colleague's script to make one (large) .ml file containing the
complete program. I'd love to have a compiler switch to tell the compiler I am producing an executable in one pass
versus creating a reusable library. The intentional differences between those two activities are huge, and apparently
still under-recognized (and thus under-used). This is surprising.
Side note: Ocaml (and Haskell) are the two languages I actively choose to code in, and get my students to code in,
after having coded in a whole bunch of languages (professionally and otherwise). When I need efficiency or
non-trivial I/O, I chose Ocaml, if I only need elegance and brevity, I choose Haskell. I still hack in Maple because
I can prototype things there faster than in most other languages (for my own work). But I am keeping up with Focal
(ex-FOC) and Epigram, as they both seem to be going where I'd like my programming languages to be. Of course, I would
rather use fewer languages! So I see it as worth my while to see Ocaml evolve.
Jacques
next prev parent reply other threads:[~2004-10-26 15:05 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-10-23 1:49 Nathaniel Gray
2004-10-23 3:31 ` Jacques Garrigue
2004-10-23 3:39 ` David Brown
2004-10-23 5:00 ` skaller
2004-10-23 21:49 ` Nathaniel Gray
2004-10-23 21:24 ` Nathaniel Gray
2004-10-23 21:33 ` Nathaniel Gray
2004-10-24 3:00 ` John Prevost
2004-10-24 5:18 ` skaller
2004-10-24 22:52 ` Nathaniel Gray
2004-10-25 13:21 ` Damien Doligez
2004-10-25 14:25 ` Jacques Carette
2004-10-26 14:07 ` Damien Doligez
2004-10-26 15:05 ` Jacques Carette [this message]
2004-10-26 17:34 ` skaller
2004-10-26 20:02 ` [Caml-list] Combined compilation and linking Jon Harrop
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=web-70171963@cgpsrv2.cis.mcmaster.ca \
--to=carette@mcmaster.ca \
--cc=caml-list@inria.fr \
--cc=damien.doligez@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