Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0007344OCamltypingpublic2016-09-05 18:292017-03-15 02:56
Reporterlpw25 
Assigned Togarrigue 
PrioritynormalSeverityminorReproducibilityalways
StatusresolvedResolutionfixed 
PlatformOSOS Version
Product Version4.03.0 
Target Version4.05.0 +dev/beta1/beta2/beta3/rc1Fixed in Version4.06.0 +dev/beta1/beta2/rc1 
Summary0007344: Inconsistent order when typing constraint patterns
DescriptionThe following code does not type-check:

  # let rec f : unit -> < m: 'a. 'a -> 'a> =
      fun () ->
        let x = f () in
        ignore (x#m 1);
        ignore (x#m "hello");
        assert false;;
  Characters 117-124:
        ignore (x#m "hello");
                    ^^^^^^^
  Error: This expression has type string but an expression was expected of type
         int

but it does if you add parentheses:

  # let rec (f : unit -> < m: 'a. 'a -> 'a>) =
      fun () ->
        let x = f () in
        ignore (x#m 1);
        ignore (x#m "hello");
        assert false;;
  val f : unit -> < m : 'a. 'a -> 'a > = <fun>

or if you add an unused polymorphic variable:

  # let rec f : 'b. unit -> < m: 'a. 'a -> 'a> =
      fun () ->
        let x = f () in
        ignore (x#m 1);
        ignore (x#m "hello");
        assert false;;
  val f : unit -> < m : 'a. 'a -> 'a > = <fun>

or if you turn on `-principal`:

  # #principal true;;
  # let rec f : unit -> < m: 'a. 'a -> 'a> =
      fun () ->
        let x = f () in
        ignore (x#m 1);
        ignore (x#m "hello");
        assert false;;
  val f : unit -> < m : 'a. 'a -> 'a > = <fun>
TagsNo tags attached.
Attached Files

- Relationships
related to 0007389acknowledgedgarrigue Can type-information flow be strengthened for non-recursive lets? 

-  Notes
(0016576)
tadeuzagallo (reporter)
2016-11-15 01:38

I understand the underlying problem is the one mentioned in the related issue, but would it make sense to fix this issue at the parsing level? I was playing with it, and unrolling `fun_binding` into `let_binding_body` and moving the constraint to the left-hand side of the binding would fix it. I don't really have any context here, so I'm sorry if that's too hacky, but I was browsing through and thought I'd mention as it'd be a tiny change.
(0016577)
gasche (developer)
2016-11-15 02:00

The problem is that for some other let-bindings of the form "let x : t = e", the current interpretation as "let x = (e : t)" is the right one, it allows you to type-check more programs (this also depends on whether the binding is recursive; see 0007389 for more discussion). In -principal mode, type-checking is made more robust by inferring less from the annotation, but then it actually requires more annotations.
(0017661)
garrigue (manager)
2017-03-15 02:56

Fixed by commit fd0dc6a0.
The type annotation is duplicated on the pattern in the first case (it is also left on the expression for propagation on both sides).
The only cases where propagation does not occur on the expression side are the second one (annotation on a parenthesized pattern), and the 3rd case (polymorphic type with variables limited to the annotations). The "let rec f : type a. ... = ..." already propagates on both sides.

- Issue History
Date Modified Username Field Change
2016-09-05 18:29 lpw25 New Issue
2016-09-07 16:43 shinwell Target Version => 4.05.0 +dev/beta1/beta2/beta3/rc1
2016-10-19 18:23 lpw25 Relationship added related to 0007389
2016-11-08 11:52 doligez Status new => acknowledged
2016-11-15 01:38 tadeuzagallo Note Added: 0016576
2016-11-15 02:00 gasche Note Added: 0016577
2017-02-23 16:45 doligez Category OCaml typing => typing
2017-03-15 02:56 garrigue Note Added: 0017661
2017-03-15 02:56 garrigue Status acknowledged => resolved
2017-03-15 02:56 garrigue Fixed in Version => 4.06.0 +dev/beta1/beta2/rc1
2017-03-15 02:56 garrigue Resolution open => fixed
2017-03-15 02:56 garrigue Assigned To => garrigue


Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker