Well,
I must say the sort of mafioso-like reasoning - "you 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:
----- Mail original -----
> On 11/15/2012 4:48 PM, Xavier Clerc wrote:I do not follow your line of thought: every information about how to
> >> 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.
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.
To be fair, I should point out that Coq is extracting camlp4 information
> 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.
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 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