[ocaml-platform] Followup to Leo's proposal

Jeremie Dimino jdimino at janestreet.com
Wed Mar 13 14:25:21 GMT 2013


On Tue, Mar 12, 2013 at 7:01 PM, Daniel Bünzli
<daniel.buenzli at erratique.ch> wrote:
> I don't really like the concept of auto-open which looks really ad-hoc to me. Did anybody investigate the idea of being:
>
> 1) able to attach values and types to namespaces instead of just modules
> 2) being able to open a namespace, bringing in scope the names it has attached to.
>
> Would it maybe help clear up some semantics issues ? For me 1) + 2) better matches the already existing concept of opening a module: this may bring new value, type, module names in your scope, but there's nothing that is "auto-opened".
>
> And (aside from the problem of how this would be concretely expressed) would that actually satisfy the proponents of "auto-open"s. Or is there something else I miss in the concept of "auto-open" ?

It makes sense to me.  At least it seems to be what we want for core/async/...

Another advantage I can see over auto-opening modules is that as soon
as someone will use one of the function of a "main/std/common"
auto-opened module, it will pull the whole module with all its maybe
unused dependencies into the final executable.


More information about the Platform mailing list