Re: [Caml-list] destructive local opens

[Gabriel Scherer <gabriel.scherer@gmail.com>]

> For ease of reasoning I think it may be a good idea to make M.(...) and
> M.!(...) behave in exactly the same way as let open and let open!
> respectively, including error messages. This would probably forbid
> distinguishing between infix operators and the rest.


Indeed, I don't think anyone planned to have (let open{,!} M in ...)
behave differently from M.{!,}(...). In fact I don't think there is
any distinction between those two constructions at the level of typing
derivations (except maybe as on-the-side annotation for
pretty-printing), so it is natural to handle them in exactly the same
way.

I proposed an implementation of the distinction between operators and
alphanumeric identifiers in
  Shadow warnings: 44 refined into 52,53 for alphanumeric identifiers
and symbolic operators
  https://github.com/ocaml/ocaml/pull/232
and this is orthogonal to the question of whether to add M.!(...), for
which a patch was proposed by Gabriel Radanne in
  Short syntax for overriding local open
  https://github.com/ocaml/ocaml/pull/218

I am of the opinion that, whether we decide to introduce M.!(...) or
not (this looks like a good idea for consistency), both (let open!)
and M.!(...) are dangerous constructions that should be avoided
whenever possible, and that we could and should drastically reduce the
number of situations where the user is encouraged to use them.

(Another idea I had was to write !<pattern>, which would have the same
semantics as <pattern>, except that it claims that the identifiers
bound in <pattern> shadow identifiers in scope. I find this syntax
cute, but the symmetry with ((!) : 'a ref -> 'a) is troubling in a bad
way.)

On Mon, Aug 17, 2015 at 12:17 PM, Nils Becker
<nils.becker@bioquant.uni-heidelberg.de> wrote:
> Sorry for the late comment.
>
> The mentioned bug:
>
>> let ox = V2.((dot v ox) * ox) in
>> V2.(3 * ox + oy)
>
> because V2 also has V2.ox sure is nasty. But the same would happen with
> a local 'let open V2'.
>
> let ox =
>     let open V2 in
>     (dot v ox) * ox in
> V2.(3 * ox + oy)
>
> For ease of reasoning I think it may be a good idea to make M.(...) and
> M.!(...) behave in exactly the same way as let open and let open!
> respectively, including error messages. This would probably forbid
> distinguishing between infix operators and the rest.
>
> (Admittedly, in the latter example one would be tempted to combine the
> local opens here which would make things clearer)
>
>> The reality is that M.() is inherently dangerous,
>
> When one uses a (destructive) local open one trades the possibility of
> ambiguity for conciseness. In a few cases the conciseness is really,
> really important, so that this trade-off is worth it. (I'm thinking
> about math.) The existence of let open! in the language says that there
> is some consensus that ambiguity is sometimes acceptable.
>
>
>>    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.
>
> It's not that bad. Destructive opens mean one has to know the shadowing
> module's signature. Only the values exported in the signature actually
> shadow anything (I just tried it out) so one does _not_ need to know the
> module source!
>
> Right now, one cannot really use M.(...) to shadow without deactivating
> warning 44. This is not ideal. With the syntax M.!(...) one would be
> forced to declare shadowing intent and 44 could be switched on. Then
>
> let ox = V2.!((dot v ox) * ox) in
> V2.!(3 * ox + oy)
>
> would still let the same bug happen but at least one was forced to write
> an exclamation mark which should give a feeling of "be careful about
> shadowing here!". Would this not be enough?
>
>
> n.
>
> --
> 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