New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Type annotations on methods cannot control the choice of abbreviation #5545
Comments
Comment author: @garrigue A solution to this problem is to use the -principal option, as it duplicates enough nodes to avoid this kind of interferences. |
Comment author: @alainfrisch
I tried that, but even for the last example, the call to "this # x" pollutes the type for method x with -principal.
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. |
Comment author: @alainfrisch Note: since commit 12289, method type are unshared in -principal mode. |
Comment author: @garrigue For the record, enabling it for normal mode has no noticeable performance cost, but increases the size of the cmi's for ocamldoc by 2% (476KB -> 486KB). |
Comment author: @alainfrisch Thanks Jacques! I've tested the patch and it works as expected. I've uploaded a diff that extends your patch with a note in Changes, a new test testsuite/tests/typing-objects/pr5545.ml, and updated expected results for two tests:
|
Comment author: @alainfrisch Something else: should we done something about the call to generalize_spine in Typeclass.initial_env? (It is currently done only in principal mode.) |
Comment author: @garrigue Committed patch_5545.diff in trunk at revision 15964. Concerning the use of generalize_spine in initial_env, its role is different.
in both normal and principal mode.
|
Comment author: @alainfrisch Thanks! What about the new warning in testsuite/tests/typing-poly/poly.ml? |
Comment author: @garrigue It is a result of the "cleaner" approach: only methods of self itself are generalized, not those of objects with the same type as self. |
Original bug ID: 5545
Reporter: @alainfrisch
Assigned to: @garrigue
Status: closed (set by @xavierleroy on 2016-12-07T10:47:27Z)
Resolution: fixed
Priority: low
Severity: tweak
Target version: 4.02.3+dev
Fixed in version: 4.03.0+dev / +beta1
Category: typing
Related to: #5619
Monitored by: @jmeber
Bug 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
File attachments
The text was updated successfully, but these errors were encountered: