From: Tiphaine Turpin <tiphaine.turpin@free.fr>
To: caml-list@inria.fr
Subject: Re: [Caml-list] [ANN] TypeRex release 1.0.0 candidate 1
Date: Tue, 06 Mar 2012 15:27:59 +0100 [thread overview]
Message-ID: <4F561EEF.5090006@free.fr> (raw)
In-Reply-To: <20120306120209.GA25938@upsilon.cc>
On 06/03/2012 13:02, Stefano Zacchiroli wrote:
> [...]
> At the same time, I'm not thrilled at the idea of having to use a
> different ocamlc just to benefit from TypeRex. Having to do so brings a
> number of disadvantages, the first and foremost being that now the
> programmer needs to worry about having synchronized versions of the
> "legacy" ocamlc installed on his machine and the version shipped by
> TypeRex.
First, a small precision (which may not be obvious from TypeRex
documentation): as the ocp-ocamlc, ... commands are only wrappers, they
are not tied to a particular version of the actual compilers they call.
In fact the following three components are somehow independent:
- the installed OCaml compilers (currently only 3.12.* is supported,
because by mistake we forgot to include 3.11 compatibility, will be
fixed in 1.0.0)
- TypeRex (with ocp-type and ocp-ocamlc, etc.)
- the OCaml compiler used to compile TypeRex (since rc2, >=3.11 works)
However, TypeRex won't be able to handle new language constructs that
are introduced in OCaml after we extract its front-end, which implies that:
- we will have too follow closely the language evolutions and we will
release a new version of TypeRex for each major release of OCaml.
- using Typerex for developping the OCaml compiler prevents you to use
the new language constructs that you introduce, until TypeRex is itself
updated.
> But there are more disadvantages, unfortunately.
>
> Can you tell us why we can't (or maybe *when* we will be able to :-))
> have the nice features offered by TypeRex on top of the stock ocamlc
> compiler?
We would like to have the binary annotation feature included in the next
release of OCaml. Before proposing a patch upstream, we wanted to
stabilize the changes in the compiler and prove them to be generic
enough. But there are two alternatives to having binary annotations in
OCaml:
- improve the ease of use of the wrappers (there have been interesting
suggestions in this direction on the issue tracker)
- integrate with a build system (which would also replace the ad-hoc
.typerex file)
Tiphaine
prev parent reply other threads:[~2012-03-06 14:28 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-22 18:10 Tiphaine Turpin
2012-02-22 17:32 ` Dmitry Grebeniuk
2012-02-22 17:45 ` Thomas Gazagnaire
2012-02-22 20:55 ` Daniel Bünzli
2012-02-23 0:46 ` Daniel Bünzli
2012-02-23 1:04 ` [Caml-list] " Hongbo Zhang
2012-02-23 11:22 ` Thomas Gazagnaire
2012-03-02 19:51 ` [Caml-list] " Vu Ngoc San
2012-03-02 20:01 ` Çagdas Bozman
2012-03-06 12:02 ` Stefano Zacchiroli
2012-03-06 14:27 ` Tiphaine Turpin [this message]
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=4F561EEF.5090006@free.fr \
--to=tiphaine.turpin@free.fr \
--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