Re: [Caml-list] Record field disambiguation in 4.01

[Goswin von Brederlow <goswin-v-b@web.de>]

On Sun, Mar 10, 2013 at 10:33:14AM +0100, Gabriel Scherer wrote:
> In case some people feel the need for more context here, the feature that
> is discussed was explained in a blog post of Alain Frisch:
>   http://www.lexifi.com/blog/type-based-selection-label-and-constructors
> 
> On Sun, Mar 10, 2013 at 4:04 AM, Markus Mottl <markus.mottl@gmail.com>wrote:
> 
> > On Sat, Mar 9, 2013 at 6:39 PM, Yaron Minsky <yminsky@gmail.com> wrote:
> > > A few concerns: one, it's really hard to figure out where the source
> > > of the conflict is from this message.  It would be nice to get some
> > > clue from the compiler as to the two definitions that are conflicting.
> >
> > I haven't investigated this, but my bet would be that the ambiguity is
> > due to the record in the Core.Std.Date module (y = year).

One more reason to be careful with using open.

On Sat, Mar 09, 2013 at 06:39:56PM -0500, Yaron Minsky wrote:
> open Core.Std
>
> type posn = { x: float; y: float }
>
> let cross_product p1 p2 =
>   p1.x *. p2.y -. p1.y *. p2.x
> ;;
>
> And when I try to compile this, I get the following error:
>
> File "geometry.ml", line 68, characters 13-14:
> Warning 41: this use of y is ambiguous.
> File "geometry.ml", line 1:
> Error: Error-enabled warnings (1 occurrences)
> Command exited with code 2.
>
> This can be fixed by adding an annotation:
>
> let cross_product p1 (p2:posn) =
>   p1.x *. p2.y -. p1.y *. p2.x
> ;;

I think this show a problem of how types propagate only in one direction.

p1 and p2 are both the same type but p1 gets infered corectly while p2
needs the type annotation to avoid a warning. Lets look at the types:

let cross_product p1 p2 =
      'a          'b 'c               | nothing known yet
   p1.x *. p2.y -. p1.y *. p2.x
   ^ label "x" --> posn
           ^ label "y" --> posn or Date
        ^ float -> float -> float

The "y" is ambiguous but just looking at the .* makes the type Date
impossible since Date.y is an integer (I assume). But the information
doesn't flow that way. Looking further:

                  ^ label "y" --> posn or Date, but we already know p1 is posn
                          ^ label "x" --> posn, too late for the warning
                        ^ float -> float -> float

The use of p2.x fixes the type of p2 to posn. But the information
comes too late for the warning when using p2.y. Again, it doesn
t flow that way.

It would be nice if the type inference and disambiguation would allow
type information to flow both ways. Not just from first use to last
but also from last use to first. Up, down, left and right in the tree
representation of the code.

Maybe the use of p2.y with .* (or in general disambiguation on the
expected type of the label) because it could lead to hard to follow
resolution of ambiguous record use. But the p2.x is a clear indication
of what type the programmer wanted.

MfG
	Goswin