[ocaml-platform] Idea: use (possibly extended) toplevel directives as source headers

[Daniel Bünzli]

Le mardi, 19 mars 2013 à 12:29, Gabriel Scherer a écrit :

> Interleaved with the namespace discussion, there is a debate about the
> amount of program semantics that should or not be encoded through
> command-line options and more generally the build system.

Sources should be reasonably self-describing, and I think we should have in source code what is needed to correctly compile the unit. Correctly in the sense with the semantics the author intended.  

A very clear example for me is non-composable camlp4-like meta-programming facilities whose final result may depend on the order they are applied. This order should be specified in the source.  

Opening a namespace, if it brings up names in your scope, seems also better to have in the module, so that the semantics of your unit doesn't change according to the order of command line arguments.  

Libraries is less clear. You can specify them in any order on the command line (except if they have dependencies among themselves), to get the same semantic result. So it seems less important to me and module usage in the unit already dictates what the environment needs to provide (as I already said a few times before systems that force you to declare every module that will be used by the unit don't bring you anything but noise).

For libraries you could tell me but then you can replace a module by another and that could potentially change the semantics so they should also be specified too according to the above principle. But I still think it's better to leave that to the environment so that you can easily swap a module implementation by another with the same semantics, which is something you will want to do at a certain point in practice (functorizing everything is not a solution, as is shown in this presentation [1]).  

In any case what I would like is not to have to repeat myself. So if we put more in the sources, I don't want to have to repeat that elsewere in the build system and/or want a way to access that information to generate the various pieces of meta-data needed by package systems.  

Daniel


[1] http://www.cis.upenn.edu/~bcpierce/papers/modules-icfp.ps