Re: [Caml-list] destructive local opens

[octachron <octa@polychoron.fr>]

[-- Attachment #1: Type: text/plain, Size: 2120 bytes --]

 From my point of view, a prefixed notation M.+ does not replace all use 
case of local opens, for at least two reasons:

     1. It makes operators harder to spot since I can not rely any more 
on the first character
     2. It adds syntactic noise and thus decreases readability within 
the DSL

As an illustration, a simple rotation

    (** Rotation on the vect(x,y) plane with an angle t
         precondition: x and y are orthonormal  *)
    let rotation (x,y) t v = let open V in
      v
       + R.( ( cos t - 1. ) * (v|*|x) - sin t * (v|*|y) ) * x
       + R.( sin t * (v|*|x) + ( cos t - 1. ) * (v|*|y) ) * y

(where V is a vector module, R the associated real-like field and |*| 
the scalar product)
becomes

    let rotation (x,y) t v =
      v
       V.+ ( ( cos t R.- 1. ) R.* ( v V.|*| x ) R.- sin t R.* ( v V.|*|
    y ) ) V.* x
       V.+ ( sin t R.* ( v V.|*| x ) R.+ ( cos t R.- 1. ) R.* ( v V.|*|
    y ) ) V.* y

  with your proposition.

In this second version, I have a hard time separating the different 
subexpressions, and I don't think it would improve much with a better 
familiarity with the syntax.

At the same time, I do agree that it would be nice to be able to use 
operators as operators without having to bring them in the local scope.

-- octachron

Le 08/19/15 17:55, Simon Cruanes a écrit :
> This whole thread makes me wonder whether local opens are worth it. I 
> don't like global open (at all), and shadowing is harmful even in 
> smaller scopes. Local open seems to be used for DSL that have a lot of 
> infix operators (maths, etc.) as demonstrated by the proposal of new 
> warnings and syntax about shadowing of infix operators.
>
> If modules have short names (Z, Q from Zarith come to mind, but 
> module-aliasing your favorite monad to "M" would do too), would M.+ be 
> a reasonable infix operator? I would be ready to have slightly more 
> verbose calls to M.>>= if it removes ambiguity and potential shadowing 
> bugs. Of course I don't know if this is compatible with the current 
> syntax.
>
> -- 
> Simon 


[-- Attachment #2: Type: text/html, Size: 3006 bytes --]