Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0005545OCamlOCaml typingpublic2012-03-20 10:232015-02-26 22:08
Assigned Togarrigue 
PrioritylowSeveritytweakReproducibilityhave not tried
PlatformOSOS Version
Product Version 
Target Versionafter-4.02.2Fixed in Version 
Summary0005545: Type annotations on methods cannot control the choice of abbreviation
DescriptionWhen using type abbreviations, annotations usually allow the programmer to pick an explicit choice for naming the type of a sub-expression:

type foo = int

let foo =
  let x : foo = 10 in
  let y : int = x in
  (x, y)

--> val foo : foo * int

For objects, this does not work so well:

class o =
    method x : foo = 10
    method y : int = this # x

--> class o : object method x : foo method y : foo end

Note that despite the type annotation on method y, the inferred type is "foo", not "int". We can get "int" by putting the annotation on the body:

class o =
    method x : foo = 10
    method y = (this # x : int)

--> class o : object method x : foo method y : int end

However, this does not work in general. In the following example, the definition of method y "pollutes" the type inferred for method x, and I cannot see a way to force the type-checker to report type "int" (without touching the definition for y):

class o =
    method x : int = (10 : int)
    method y = (this # x : foo)

--> class o : object method x : foo method y : foo end

TagsNo tags attached.
Attached Files

- Relationships

-  Notes
garrigue (manager)
2012-03-21 08:30

A solution to this problem is to use the -principal option, as it duplicates enough nodes to avoid this kind of interferences.
Whether this should be done in all cases is another question. Originally, the unification algorithm was designed so as to propagate abbreviations. You are suggesting that this behavior is wrong in some cases.
Note that here int and foo are supposed to be strictly equivalent. The semantics of ocaml do not distinguish between the two.
The only place where abbreviations are guaranteed to be kept is in interfaces. Indeed, if foo is made abstract there, they would be different.
frisch (developer)
2012-03-21 10:08

> A solution to this problem is to use the -principal option

I tried that, but even for the last example, the call to "this # x" pollutes the type for method x with -principal.

> Originally, the unification algorithm was designed so as to propagate abbreviations.

I'm surprised by the difference between standard let definitions, where type annotations seem to be enough to have the type-checker picks the desired name, and typing of objects.

- Issue History
Date Modified Username Field Change
2012-03-20 10:23 frisch New Issue
2012-03-21 08:30 garrigue Note Added: 0007119
2012-03-21 08:36 garrigue Assigned To => garrigue
2012-03-21 08:36 garrigue Status new => assigned
2012-03-21 10:08 frisch Note Added: 0007120
2012-09-06 16:43 doligez Target Version => 4.00.1+dev
2012-09-21 13:29 doligez Target Version 4.00.1+dev => 4.01.0+dev
2013-08-19 14:30 doligez Target Version 4.01.0+dev => 4.01.1+dev
2014-05-25 20:20 doligez Target Version 4.01.1+dev => 4.02.0+dev
2014-07-16 20:49 doligez Target Version 4.02.0+dev => 4.02.1+dev
2014-09-04 00:25 doligez Target Version 4.02.1+dev => undecided
2014-09-22 22:10 doligez Target Version undecided => 4.02.2+dev
2015-02-26 22:08 doligez Target Version 4.02.2+dev => after-4.02.2

Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker