Original bug ID: 6331 Reporter:@lpw25 Assigned to:@garrigue Status: closed (set by @xavierleroy on 2015-12-11T18:25:45Z) Resolution: fixed Priority: normal Severity: minor Version: 4.01.0 Fixed in version: 4.02.0+dev Category: typing Monitored by:@gasche
The is_fixed_type function in "typedecl.ml" does not take account of nested
aliases. For example,
# type t = private < x : int; .. > as 'a;;
type t = private < x : int; .. >
# type t = private (< x : int; .. > as 'a) as 'a;;
type t = private (< x : int; .. > as 'a) as 'a;;
Error: A type variable is unbound in this type declaration.
In type < x : int; .. > as 'a the variable 'a is unbound
and probably more concerning
# type t = private < x : int > as 'a;;
type t = private < x : int > as 'a;;
Error: This fixed type has no row variable
# type t = private (< x : int > as 'a) as 'b;;
type t = private < x : int >
The text was updated successfully, but these errors were encountered:
Actually, the problem is rather that the distinction between private abbreviations and private row types is made on a purely syntactic, and you get an error if the system guessed wrong. I agree that the guessing could be improved: in your example the object type has syntactically no row variable, so both cases should succeed; symmetrically, having several aliases should not change the behavior (but I'm not sure why one would want to pile up aliases in this way).
Note that one can already force a private abbreviation by using a constraint:
type t = private 'a constraint 'a = <x:int>
Another approach would be to do it more semantically: produce a private row type if the type has an unbound row, independently of the syntax. The problem is that it might behave in unexpected ways: a type that syntactically it looks like a private row type could end up generating a private abbreviation.
For instance the following is already accepted
type 'a t = <x:'a> as 'a
type u = private 'b constraint 'b = <x:'b t; ..>
and the semantic approach would allow
type u = <x:'b t; ..> as 'b
Fixed in trunk at revision 14443, following the "Another approach".
Now all for cases are accepted, creating a private abbreviation or a private row depending of whether .. is used or not ('as' doesn't matter).