0005545: Type annotations on methods cannot control the choice of abbreviation - MantisBT

Mantis Bug Tracker

View Issue Details [ Jump to Notes ]

[ Issue History ] [ Print ]

ID

Project

Category

View Status

Date Submitted

Last Update

0005545

OCaml

OCaml typing

public

2012-03-20 10:23

2012-09-21 13:29

Reporter

frisch

Assigned To

garrigue

Priority

low

Severity

tweak

Reproducibility

have not tried

Status

assigned

Resolution

open

Platform

OS

OS Version

Product Version

Target Version

4.01.0+dev

Fixed in Version

Summary

0005545: Type annotations on methods cannot control the choice of abbreviation

Description

When 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 =
  object(this)
    method x : foo = 10
    method y : int = this # x
  end

--> 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 =
  object(this)
    method x : foo = 10
    method y = (this # x : int)
  end

--> 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 =
  object(this)
    method x : int = (10 : int)
    method y = (this # x : foo)
  end

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

Tags

No tags attached.

Relationships

Notes
(0007119) 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.

(0007120) 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

Copyright © 2000 - 2011 MantisBT Group