Browse thread
[Caml-list] Single-case union types as strong typedefs
[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
| Date: | -- (:) |
| From: | Jacques Carette <carette@m...> |
| Subject: | Re: [Caml-list] Single-case union types as strong typedefs |
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