Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0007565OCamltypingpublic2017-06-23 16:342018-11-24 21:10
Assigned Tooctachron 
PrioritylowSeverityfeatureReproducibilityhave not tried
PlatformOSOS Version
Product Version 
Target VersionFixed in Version4.08.0+dev/beta1 
Summary0007565: Puzzling error message with free type variables
DescriptionConsider the following code:

class type t_a =
    method f: 'a. 'a -> int

let f (o:t_a) = o # f 0

let () =
  let o =
      method f _ = 0
  f o

We got the following error message:

Error: This expression has type < f : 'a -> int >
       but an expression was expected of type t_a
       The universal variable 'a0 would escape its scope

The error message is puzzling because there is no 'a0 in the inferred type.
TagsNo tags attached.
Attached Files

- Relationships
child of 0007338confirmed meta-issue on confusing type error messages 

-  Notes
octachron (developer)
2017-06-23 16:59
edited on: 2017-06-23 17:07

To trace the origin of the 'a0 type name in error message, one can rename the universal variable 'a in the definition of the class type to:

class type t_a =
    method f: 'any. 'any -> int

The error message becomes then

Error: This expression has type < f : 'a -> int > but an expression was expected of type t_a The universal variable 'any would escape its scope

In other words, the type variable name `'a0` in the original error message is a type name derived from the name used in the explicitly polymorphic annotation "f:'a. …". The "0" suffix is then added to discrimate between this universal type variable "'a" and the type variable "'a" in scope at the point of the error.

I think that it could be nice to make the origin of the derivation more apparent. For instance, printing "'a(universal)" in the error message? It may also be worthwhile to add the location of the definition of the universal type variable (if possible).

lpw25 (developer)
2017-06-23 22:33

I think the best change in this case would be to show the expansion of t_a in the message. Then it would be clear where it came from. There is probably some case missing in to handle this, but I've never really understood that code so maybe it's more complicated than that.
octachron (developer)
2017-06-24 03:19

Expanding the object type of t_a sounds like a good idea; and after looking at the code it seems that this is just a matter of disabling the compact mode in Printtyp.may_prepare_expansion when there is an escaping universal type variable error message laying in ambush.
octachron (developer)
2017-06-24 15:03

I have an implementation PR for the type expansion solution here: [^] .
octachron (developer)
2018-11-24 21:10

This issue should been fixed in OCaml 4.08 by [^] , which adds some context about the method type when an universal variable escapes. For instance, the error message in the reported example becomes

Error: This expression has type < f : 'a -> int >
       but an expression was expected of type t_a
       The method f has type 'a -> int, but the expected method type was
       'a0. 'a0 -> int
       The universal variable 'a0 would escape its scope

- Issue History
Date Modified Username Field Change
2017-06-23 16:34 sbriais New Issue
2017-06-23 16:59 octachron Note Added: 0017966
2017-06-23 17:02 octachron Priority normal => low
2017-06-23 17:02 octachron Severity minor => feature
2017-06-23 17:02 octachron Status new => confirmed
2017-06-23 17:04 octachron Relationship added child of 0007338
2017-06-23 17:07 octachron Note Edited: 0017966 View Revisions
2017-06-23 22:33 lpw25 Note Added: 0017973
2017-06-24 03:19 octachron Note Added: 0017974
2017-06-24 15:02 octachron Assigned To => octachron
2017-06-24 15:02 octachron Status confirmed => assigned
2017-06-24 15:03 octachron Note Added: 0017976
2018-11-24 21:10 octachron Note Added: 0019483
2018-11-24 21:10 octachron Status assigned => resolved
2018-11-24 21:10 octachron Fixed in Version => 4.08.0+dev/beta1
2018-11-24 21:10 octachron Resolution open => fixed

Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker