From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id 8750C7EE4B for ; Wed, 16 Oct 2013 02:12:23 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of wojciech.meyer@gmail.com) identity=pra; client-ip=74.125.82.182; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="wojciech.meyer@gmail.com"; x-sender="wojciech.meyer@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of wojciech.meyer@gmail.com designates 74.125.82.182 as permitted sender) identity=mailfrom; client-ip=74.125.82.182; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="wojciech.meyer@gmail.com"; x-sender="wojciech.meyer@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-we0-f182.google.com) identity=helo; client-ip=74.125.82.182; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="wojciech.meyer@gmail.com"; x-sender="postmaster@mail-we0-f182.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0CALLYXVJKfVK2lGdsb2JhbABagkN8Uq9JihaIS4EbCBYOAQEBAQcLCwkSKoIlAQEEAScZARsSCwEDAQsGBQsaISIBEQEFAQoSBhMSCYdYAQMJBgyfQIxVgwqEKgoZJwMKZIkBAQUMjzoEB4QlA5gEgS+OaBgpgmUrgT87 X-IPAS-Result: Av0CALLYXVJKfVK2lGdsb2JhbABagkN8Uq9JihaIS4EbCBYOAQEBAQcLCwkSKoIlAQEEAScZARsSCwEDAQsGBQsaISIBEQEFAQoSBhMSCYdYAQMJBgyfQIxVgwqEKgoZJwMKZIkBAQUMjzoEB4QlA5gEgS+OaBgpgmUrgT87 X-IronPort-AV: E=Sophos;i="4.93,503,1378850400"; d="scan'208";a="37197249" Received: from mail-we0-f182.google.com ([74.125.82.182]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 16 Oct 2013 02:12:21 +0200 Received: by mail-we0-f182.google.com with SMTP id t61so6121wes.41 for ; Tue, 15 Oct 2013 17:12:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0EY2yPI/iC0HALDrhz9AFegDna0C/oPgC150mO7K4ps=; b=obM2T6wtRH0p+pnjLMIF+fjK0ARYjaDGDC5geyg3xfh81HND5VDDRvUA7XHwEvKJvD AnN40jPTaSlB6ZpkZFBw6O+lUjoLYjMIs5T7V5OTCLBYC5AEYEoYtknpxNcNctb+HeV5 XCjpXK2hS08PHMBbeYQvuCkwlCsJz6CemCvapac/UzWxW+pyXuKLato8FoVrx7SYhsRl rV0YNO4K83bKjSAAPKGG4NarZ5kYrsHSTo4odPsXgm8IPIyNhSmXwS/8MLdetnUMzsuA zoQGdCF2FR82GlIQCtb0EAaU5cRkfYBQieqWS0/QS6GiR/EazTYsAbKJ9p1/UTrFNc+O Rzag== MIME-Version: 1.0 X-Received: by 10.180.89.206 with SMTP id bq14mr21807476wib.56.1381882342863; Tue, 15 Oct 2013 17:12:22 -0700 (PDT) Received: by 10.216.72.66 with HTTP; Tue, 15 Oct 2013 17:12:22 -0700 (PDT) In-Reply-To: <0a437177279677820a760c6912757fac@kerneis.info> References: <20131015124116.GA7090@kerneis.info> <20131015132216.GC7090@kerneis.info> <0a437177279677820a760c6912757fac@kerneis.info> Date: Wed, 16 Oct 2013 01:12:22 +0100 Message-ID: From: Wojciech Meyer To: Gabriel Kerneis Cc: Caml List Content-Type: multipart/alternative; boundary=e89a8f3b9da92af73d04e8d08e74 Subject: Re: [Caml-list] [ocaml-jobs] Developper position: designing a C front-end in OCaml --e89a8f3b9da92af73d04e8d08e74 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable [now to the list, apart from Gabriel] Hello, In general, the AST transformation should be gradual, like in logic rewriting systems kind of Maude. So the AST definitions should be lightweight as possible and passes declarative. In the end you have a "final" OCaml AST, with types or without, with blank tokens and comments or without, and it would be CIL or something else depending what you want. I am not opposing inventing new frontend, but would rather think what kind of goodness we can get from the existing solutions. I think sticking with Clang (or gcc) as a frontend and exporting, maybe automatically the AST looks like a sane solution, as a bonus we have a C++ frontend that passes all the conformance testing. hope that helps, Wojciech On Tue, Oct 15, 2013 at 10:36 PM, Gabriel Kerneis wro= te: > Le 2013-10-15 19:29, Dmitry Grebeniuk a =E9crit : > > We are talking about changing the AST used to manipulate the programs. >>> Changing it (in either CIL or Frama-C) would mean breaking every >>> existing code around the world based on it. >>> >> >> I don't think so. Imagine that "C source -> CIL representation >> (available to code based on CIL)" could be enhanced to "C source -> >> Very Concrete C AST -> CIL representation". Old users are happy, new >> users have access to Very Concrete C AST. >> > > Oh, this is already the case. "Very concrete AST" is the > "FrontC" project mentionned elsewhere in this thread. > > -- > Gabriel > > > -- > Caml-list mailing list. Subscription management and archives: > https://sympa.inria.fr/sympa/**arc/caml-list > Beginner's list: http://groups.yahoo.com/group/**ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-**bugs > --e89a8f3b9da92af73d04e8d08e74 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
[now to the list, apart from Gabriel]
Hello,

In gen= eral, the AST transformation should be gradual, like in logic rewriting sys= tems kind of Maude. So the AST definitions should be lightweight as possibl= e and passes declarative. In the end you have a "final" OCaml AST= , with types or without, with blank tokens and comments or without, and it = would be CIL or something else depending what you want.

I am not opposing inve= nting new frontend, but would rather think what kind of goodness we can get= from the existing solutions. I think sticking with Clang (or gcc) as a fro= ntend and exporting, maybe automatically the AST looks like a sane solution= , as a bonus we have a C++ frontend that passes all the conformance testing= .

hope that helps,
=
Wojciech


On Tue, Oct 1= 5, 2013 at 10:36 PM, Gabriel Kerneis <gabriel@kerneis.info> wrote:
Le 2013-10-15 19:29, Dmitry Grebeniuk a =E9c= rit=A0:

We are talking about changing the AST used to manipulate the programs.
Changing it (in either CIL or Frama-C) would mean breaking every
existing code around the world based on it.

=A0 I don't think so. =A0Imagine that "C source -> CIL represen= tation
(available to code based on CIL)" could be enhanced to "C source = ->
Very Concrete C AST -> CIL representation". =A0Old users are happy,= new
users have access to Very Concrete C AST.

Oh, this is already the case. =A0"Very concrete AST" is the
"FrontC" project mentionned elsewhere in this thread.

--
Gabriel


--
Caml-list mailing list. =A0Subscription management and archives:
ht= tps://sympa.inria.fr/sympa/arc/caml-list
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners<= /a>
Bug reports: http://caml.inria.fr/bin/caml-bugs

--e89a8f3b9da92af73d04e8d08e74--