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 mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by sympa.inria.fr (Postfix) with ESMTPS id 568077EE86 for ; Fri, 16 Nov 2012 11:34:03 +0100 (CET) Received-SPF: None (mail4-smtp-sop.national.inria.fr: no sender authenticity information available from domain of arnaud.spiwack@gmail.com) identity=pra; client-ip=209.85.210.182; receiver=mail4-smtp-sop.national.inria.fr; envelope-from="arnaud.spiwack@gmail.com"; x-sender="arnaud.spiwack@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail4-smtp-sop.national.inria.fr: domain of arnaud.spiwack@gmail.com designates 209.85.210.182 as permitted sender) identity=mailfrom; client-ip=209.85.210.182; receiver=mail4-smtp-sop.national.inria.fr; envelope-from="arnaud.spiwack@gmail.com"; x-sender="arnaud.spiwack@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail4-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-ia0-f182.google.com) identity=helo; client-ip=209.85.210.182; receiver=mail4-smtp-sop.national.inria.fr; envelope-from="arnaud.spiwack@gmail.com"; x-sender="postmaster@mail-ia0-f182.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvkBAGQWplDRVdK2mGdsb2JhbABEhh6pdjOJBQGIdwgjAQEBAQEICQ0HFCeCHgEBBAEjHQESGwsBAwELAQUFCw0NHQICIhIBBQEKEgYTEgmHYAMJBgufMYtkg0eFEycDColOAQUMjCUUBoNggRMDkkqDMoEcihiDLhYpgViCOoFaCRc X-IronPort-AV: E=Sophos;i="4.83,264,1352070000"; d="scan'208";a="162718861" Received: from mail-ia0-f182.google.com ([209.85.210.182]) by mail4-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 16 Nov 2012 11:33:47 +0100 Received: by mail-ia0-f182.google.com with SMTP id x2so2774700iad.27 for ; Fri, 16 Nov 2012 02:33:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=Oig/984ry+qgoyZ/N7AQtm3Z42mxEbriwyiWxm6isoA=; b=lcEaOSQQhJkUhn2RwAijlp9pa9PmH2Rb+2FZi00HAJwZQaAlJFe+X5XqOf826/7aBz /kgpNYiu18ecbNamFYNIjeQOK3P5Q14V5lVmkSXRa+Mo4GDAdCup5KGCsui7YCa0rp8n 6uFN99xU11t4/bxmfsfzX89a3doQAp0NRA+PMsTjRt6Pm1PTiJruHzzoAird8eaTRWP1 kxcnlVIBw7zhMz1sQHo8wH5M6cpwhN2POnw/u+3IFLdkNFfr4tUYhzvd5Y6TQC3mSX6l O3rqz1qcyRcULjXfbFtWm5Fp9Jp5oOh96B4Nj9Ljss9kKOR2IMzTmupJ+Cg6Pcr3v8w1 KymQ== Received: by 10.50.152.236 with SMTP id vb12mr2777839igb.15.1353062026314; Fri, 16 Nov 2012 02:33:46 -0800 (PST) MIME-Version: 1.0 Sender: arnaud.spiwack@gmail.com Received: by 10.64.43.199 with HTTP; Fri, 16 Nov 2012 02:33:06 -0800 (PST) In-Reply-To: <331585634.4160435.1353019001535.JavaMail.root@inria.fr> References: <50A56709.7080105@gmail.com> <331585634.4160435.1353019001535.JavaMail.root@inria.fr> From: Arnaud Spiwack Date: Fri, 16 Nov 2012 11:33:06 +0100 X-Google-Sender-Auth: u0T8MyJga7wXMRNU-D637KTOCXU Message-ID: To: Xavier Clerc Cc: Edgar Friendly , OCaML Mailing List Content-Type: multipart/alternative; boundary=e89a8f3ba02970027f04ce9a4de7 Subject: Re: [Caml-list] About ocamlbuild --e89a8f3ba02970027f04ce9a4de7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Well, I must say the sort of mafioso-like reasoning =C2=AD- "you really do not wa= nt to do that" - doesn't really make sense to me. Here are valid reasons not to include a feature X in a tool: - I don't have time to do X - I don't know how to do X - Having X would prevent me from having Y which I'd rather Any other reason is bad. People want to have tags and compilation pragmas? Well, let them, they probably have valid reasons to (some options may be better seen global to the project and other local to files). People want to interleave compiling the build system and compiling the project. They have a good reason for that too. Also: ocamlbuild doesn't only compile ocaml files. Related to that last point, and to the initial question: as far as I'm aware, an ocamlbuild plugin cannot depend on a custom library (to go around that we can use a myocamlbuild.ml which compiles a mymyocamlbuild.ml (or something) with the appropriate linking options, then copy it in a _build_stage2 directory, then Unix.excv an ocamlbuild -no-plugin -build-dir _build_stage2. It would be nice if there were a standard and simple way to do this sort of thing). In particular there is no principled way to distribute a tool together with an ocamlbuild library against which to compile our myocamlbuild.ml plugins (hence extending what ocamlbuild can "natively" compile). On 15 November 2012 23:36, Xavier Clerc wrote: > ----- Mail original ----- > > On 11/15/2012 4:48 PM, Xavier Clerc wrote: > > >> 3 - Finally, I find the idea of tags good, for backward > > >> compatibility > > >> reasons (you do not have to change your code), but not enough. For > > >> instance, in haskell (and some compilers written in ocaml), you > > >> can > > >> add "tags" at the beginning of your files. You would start your > > >> ocaml files with comments such as: > > >> > > >> (* #OPTIONS -rectypes *) > > > Well, I find tags pretty convenient, and do not dislike the comment > > > approach. However, I am pretty sure I do not want the related > > > information > > > to be scattered over multiple locations. > > It's exactly this reason that I'm strongly in favor of magic comments > > or > > pragmas or something in .ml files to do do this kind of thing. > > Splitting the data needed to compile a module into two parts: the > > module > > and a makefile (or _tags or OMakefile or whatever) seems a violation > > of > > your "multiple locations" policy. > > I do not follow your line of thought: every information about how to > compile is clearly in build files, and not in source code files. > If I wonder how the command-line for a given compilation is determined, > there is only one place to look. > > Again, I do not claim that the current state of affairs (everything > in build files) is better than a pure pragma-based solution (everything > in source files). My objection is about a mixed system where one should > have to consult both build and source file in order to know which > options are passed to compile a given module. > > > > While I grant that some > > compilation > > options (whether to compile in debug/profiling/native mode, location > > of > > external libraries) should not be included in a source file, I'm > > strongly in favor of having the build system work out the details of > > dependencies (internal to project and external, installed in global > > location) and even what camlp4 to run based on the contents of the > > file > > itself and not elsewhere. > > To be fair, I should point out that Coq is extracting camlp4 information > from source files in order to determine how to treat them. > > > Just a final remark: compared to Haskell, OCaml compilers feature a limit= ed > number of command-line switches having an influence on the semantics of a > source file(*). I regard this as a pleasant thing, and think this makes t= he > issue at hand quite minor. > > > Kind regards, > > Xavier Clerc > > > > > (*) we are only talking about labels, applicative functors, and recursive > types > > -- > 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 > --e89a8f3ba02970027f04ce9a4de7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Well,

I must say the sort of mafioso-like reasoning =C2=AD- "yo= u really do not want to do that" - doesn't really make sense to me= .

Here are valid reasons not to include a feature X in a tool:
  • I don't have time to do X
  • I don't know how to do X
    • =
  • Having X would prevent me from having Y which I'd rather
    • A= ny other reason is bad.

    People want to have tags and compilation pra= gmas? Well, let them, they probably have valid reasons to (some options may= be better seen global to the project and other local to files). People wan= t to interleave compiling the build system and compiling the project. They = have a good reason for that too. Also: ocamlbuild doesn't only compile = ocaml files.

    Related to that last point, and to the initial question: as far as I= 9;m aware, an ocamlbuild plugin cannot depend on a custom library (to go ar= ound that we can use a myocamlbuild.ml which compiles a mymyocamlbuild.ml<= /a> (or something) with the appropriate linking options, then copy it in a = _build_stage2 directory, then Unix.excv an ocamlbuild -no-plugin -build-dir= _build_stage2. It would be nice if there were a standard and simple way to= do this sort of thing). In particular there is no principled way to distri= bute a tool together with an ocamlbuild library against which to compile ou= r myocamlbuild.ml plugins (hence ext= ending what ocamlbuild can "natively" compile).



    On 15 Nov= ember 2012 23:36, Xavier Clerc <xavier.clerc@inria.fr> w= rote:
    ----- Mail original -----
    > On 11/15/2012 4:48 PM, Xavier Clerc wrote:
    > >> 3 - Finally, I find the idea of tags good, for backward
    > >> compatibility
    > >> reasons (you do not have to change your code), but not enough= . For
    > >> instance, in haskell (and some compilers written in ocaml), y= ou
    > >> can
    > >> add "tags" at the beginning of your files. You woul= d start your
    > >> ocaml files with comments such as:
    > >>
    > >> (* #OPTIONS -rectypes *)
    > > Well, I find tags pretty convenient, and do not dislike the comme= nt
    > > approach. However, I am pretty sure I do not want the related
    > > information
    > > to be scattered over multiple locations.
    > It's exactly this reason that I'm strongly in favor of magic c= omments
    > or
    > pragmas or something in .ml files to do do this kind of thing.
    > Splitting the data needed to compile a module into two parts: the
    > module
    > and a makefile (or _tags or OMakefile or whatever) seems a violation > of
    > your "multiple locations" policy.

    I do not follow your line of thought: every information about how to<= br> compile is clearly in build files, and not in source code files.
    If I wonder how the command-line for a given compilation is determined,
    there is only one place to look.

    Again, I do not claim that the current state of affairs (everything
    in build files) is better than a pure pragma-based solution (everything
    in source files). My objection is about a mixed system where one should
    have to consult both build and source file in order to know which
    options are passed to compile a given module.


    > While I grant that some
    > compilation
    > options (whether to compile in debug/profiling/native mode, location > of
    > external libraries) should not be included in a source file, I'm > strongly in favor of having the build system work out the details of > dependencies (internal to project and external, installed in global
    > location) and even what camlp4 to run based on the contents of the
    > file
    > itself and not elsewhere.

    To be fair, I should point out that Coq is extracting camlp4 informat= ion
    from source files in order to determine how to treat them.


    Just a final remark: compared to Haskell, OCaml compilers feature a limited=
    number of command-line switches having an influence on the semantics of a source file(*). I regard this as a pleasant thing, and think this makes the=
    issue at hand quite minor.


    Kind regards,

    Xavier Clerc




    (*) we are only talking about labels, applicative functors, and recursive t= ypes

    --
    Caml-list mailing list. =C2=A0Subscription management and archives:
    ht= tps://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

    --e89a8f3ba02970027f04ce9a4de7--