Re: [Caml-list] destructive local opens

["Daniel Bünzli" <daniel.buenzli@erratique.ch>]

Le lundi, 3 août 2015 à 17:13, octachron a écrit :
> > The benefit is that I can understand what is happening by only looking at the expression I'm reading. With your proposal I also need to go read the library source to understand what is happening.
>  
> I think that it is partially true. For instance, with a vector library,  
> "*" is always quite ambiguous: Is this the original scalar  
> multiplication? The vector product? The tensor product? The external  
> product? The Clifford algebra product? These ambiguities already needs  
> to be resolved in the documentation;


Note that what you raise here is a different issue it's not about knowing *if* the operator is the one from M.() or the one in scope, but which one is implemented. Very often this can be disambiguised by the surrounding context and, if your operator are few (which they should be), is learnable in practice.

With the operator warning splitting rule. The inferences are very simple:

1. Given a M.( * ) without warning the * may be the one of M or the one in scope. Ambiguous, can't be resolved locally.

2. Given a M.( id ) without warning, if [id] is in scope I *know* this [id] is being used. If it's not I know M.id is being used. No ambiguity, can be resolved locally.

If you allow each identifier in a module to sport an @shadow annotation you lose 2. which I find a  very valuable property. Without it, given that identifiers are much more widespread than operators, we get a much more ambiguous language.

Best,

Daniel