RE: [Caml-list] destructive local opens

[David Allsopp <dra-news@metastack.com>]

Petter A. Urkedal wrote:
> 2015-08-04 11:33 GMT+02:00 Goswin von Brederlow <goswin-v-b@web.de>:
> > On Tue, Aug 04, 2015 at 08:51:34AM +0200, Petter Urkedal wrote:
> >> On 2015-08-03, Daniel Bünzli wrote:
> >> > Le lundi, 3 août 2015 à 15:08, Nils Becker a écrit :
> >> > > It's possible that people actually want M.() to mean let open!
> >> > > more often than let open. For me I think that's the case.
> >> >
> >> > If you are in the vector case, I don't think that's the case. With Gg
> [1] I often had the following kind of subtly wrong code (can't remember
> the exact details but something similar):
> >> >
> >> > let ox = V2.((dot v ox) * ox) in
> >> > V2.(3 * ox + oy)
> >> >
> >> > The reality is that M.() is inherently dangerous, especially from an
> API evolution perspective where new identifiers with matching type may get
> introduced later leading to silent semantic changes in your code. So we
> should not encourage people to use M.!() as it's going to make the problem
> even more acute. Besides we should have that 44 warning by default so that
> we see the problems, but for now it's impossible to live with 44 and a Gg
> like library.
> >>
> >> This suggests another option.  If type information is available at
> >> the point this warning is emitted, then the warning could be issued
> >> only in the case when the type of the shadowing identifier matched
> >> that of the shadowed identifier.
> >>
> >> This assumes the common case for shadowing is to redefine operators
> >> or common functions at a custom type, the use of M.() being an
> >> alternative to overloading.  Loosely the warning should be emitted if
> >> the chosen identifier is not the one which would have been chosen by
> >> some sensible overloading scheme, but instead we make a simple
> estimate.
> >>
> >> This could still go wrong, since the type required by the context may
> >> be general than the type of both the shadowed and shadowing terms, so
> >> a better rule might be to issue the warning if both are admissible in
> >> the given context, though my guess is that's harder to implement.
> >
> > I like the idea but how feasable is it? Most of the time I figure the
> > type being infered from the operator being used. The use of M.(*)
> > makes it the custom type while simple (*) would make it int. The type
> > system would have to track the ambiguity until some other use of the
> > arguments or result decide the proper type. And if it doesn't resolve
> > then emit the warning.
> 
> Yes, it's probably not that easy to implement.  Not familiar with the code
> base.  At least it requires postponing the warning till type information
> is available, and maybe cluttering the parse tree with sub-nodes
> containing the types and locations of shadowed identifiers.
> The types at the point the check is made will have been analysed under the
> assumption that the right resolution was made.

I asked similar a few years ago on the list for general let-shadowing[1].

I haven't checked whether it's still working in latest ocaml/camlp4, as I vaguely recall that if-then-else shadowing isn't correctly handled in the filter, and I ended up having to disable it in the project I was using it for, but it was a reasonably short camlp4 filter and ocamllex script to do the post-processing, so I can't imagine that this similar case would be that bad in the compiler itself. I've chucked the original code at https://github.com/dra27/pf_shadow for interest.


David


[1] http://caml.inria.fr/pub/ml-archives/caml-list/2008/08/5b882a133318d913dd7aaa0abacf36d7.en.html