Skip to content
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

`is_fixed_type` does not take account of nested aliases #6331

vicuna opened this issue Feb 18, 2014 · 2 comments


None yet
2 participants
Copy link

commented Feb 18, 2014

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

Bug description

The is_fixed_type function in "" 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;;
 Characters 5-46:
   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;;
 Characters 5-34:
   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 >

This comment has been minimized.

Copy link

commented Feb 19, 2014

Comment author: @garrigue

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


This comment has been minimized.

Copy link

commented Feb 25, 2014

Comment author: @garrigue

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).

@vicuna vicuna closed this Dec 11, 2015

@vicuna vicuna added the typing label Mar 14, 2019

@vicuna vicuna added the bug label Mar 20, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.