From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: ** X-Spam-Status: No, score=2.3 required=5.0 tests=AWL,DNS_FROM_SECURITYSAGE, HTML_00_10,HTML_MESSAGE autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by yquem.inria.fr (Postfix) with ESMTP id 2F393BBAF for ; Wed, 19 Nov 2008 15:32:10 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqQHAGuyI0lKfU4Yi2dsb2JhbACCPTOJYQGGRz4BAQEKCwoHDwW+a4J5 X-IronPort-AV: E=Sophos;i="4.33,631,1220220000"; d="scan'208";a="19335399" Received: from ey-out-2122.google.com ([74.125.78.24]) by mail3-smtp-sop.national.inria.fr with ESMTP; 19 Nov 2008 15:32:09 +0100 Received: by ey-out-2122.google.com with SMTP id 6so1336317eyi.15 for ; Wed, 19 Nov 2008 06:32:09 -0800 (PST) Received: by 10.210.52.9 with SMTP id z9mr1016927ebz.35.1227105129179; Wed, 19 Nov 2008 06:32:09 -0800 (PST) Received: by 10.210.51.13 with HTTP; Wed, 19 Nov 2008 06:32:09 -0800 (PST) Message-ID: <9722eaea0811190632l66a36f2cge1cbf7fdee5d3044@mail.gmail.com> Date: Wed, 19 Nov 2008 14:32:09 +0000 From: "Thomas Gazagnaire" To: "OCaml List" Subject: annotate a .ml file with type information MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_23030_19273657.1227105129185" X-Spam: no; 0.00; ocaml:01 camlp:01 compiler:01 overkill:01 compilation:01 patching:01 compiler:01 cheers:01 camlp:01 overkill:01 compilation:01 patching:01 cheers:01 ast:02 ast:02 ------=_Part_23030_19273657.1227105129185 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi all, I would like to write a camlp4 extension which use infered-type information. To do that, I can see two ways: * either calling an type-inference function of the compiler, giving it an AST and a context associating identifiers to types which seems to me a bit complicated (and maybe impossible), * or annotating the original source code with infered-type information - which seems to me simpler. In this case, I believe that it is not difficult to merge an ml file and its corresponding .annot file to produce a file where every identifier is type annotated, but it seems to me a bit overkill to do it at this stage as it would be simpler to do it directly after the type-inference phase of the compilation. So, patching the compiler to make it producing such a file with a special option (as -infertypes) seems also good to me. I would like to ask people what they are thinking of this problem and before starting to work on it, I wondering if someone is aware or either an existing ml-annot merger or a hidden compiler flag to produce such a file ? Or if there is a reason why it should be not possible to do so :-) Cheers, Thomas ------=_Part_23030_19273657.1227105129185 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi all,

I would like to write a camlp4 extension which use infered-type information. To do that, I can see two ways:
* either calling an type-inference function of the compiler, giving it an AST and a context associating identifiers to types which seems to me a bit complicated (and maybe impossible),
* or annotating the original source code with infered-type information - which seems to me simpler. In this case, I believe that it is not difficult to merge an ml file and its corresponding .annot file to produce a file where every identifier is type annotated, but it seems to me a bit overkill to do it at this stage as it would be simpler to do it directly after the type-inference phase of the compilation. So, patching the compiler to make it producing such a file with a special option (as -infertypes) seems also good to me.

I would like to ask people what they are thinking of this problem and before starting to work on it, I wondering if someone is aware or either an existing ml-annot merger or a hidden compiler flag to produce such a file ? Or if there is a reason why it should be not possible to do so :-)

Cheers,
Thomas
------=_Part_23030_19273657.1227105129185--