caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
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


      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;
as well as URLs for NNTP newsgroup(s).