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

Toplevel outputs "type/n" unnecessarily #8610

Closed
xclerc opened this issue Apr 11, 2019 · 6 comments

Comments

@xclerc
Copy link
Contributor

commented Apr 11, 2019

The following sequence in the toplevel:

# type list;;
type list
# let f () = [];;
val f : unit -> 'a list/2 = <fun>

seems a bit unexpected, as the "/2" is unnecessary.

(I have no idea whether it is a correct fix, but I noticed
that adding printing_env := Env.empty; to the
Printtyp.Naming_context.reset function seemingly
fixes the problem.)

@xclerc

This comment has been minimized.

Copy link
Contributor Author

commented Apr 11, 2019

@xclerc xclerc changed the title Toplevel outputs " Toplevel outputs "type/n" unnecessarily Apr 11, 2019
@Octachron

This comment has been minimized.

Copy link
Contributor

commented Apr 11, 2019

This can be easily disabled, but this is a conscious choice due to the fact that the type constructor list in the type of f is not the one currently in scope.
For instance, without this differentiation copying the type displayed by the toplevel and adding it as a constraint to f,

let g: unit -> 'a list = f

yields an error.

@xclerc xclerc closed this Apr 11, 2019
@xclerc

This comment has been minimized.

Copy link
Contributor Author

commented Apr 11, 2019

OK, thanks for the explanation.

@trefis

This comment has been minimized.

Copy link
Contributor

commented Apr 11, 2019

I think there something @xclerc omitted from his original message, so let me expand on his example:

# type list;;
type list
# [ 1 ];;
- : int list = [1]
# let l = [ 1 ];;
val l : int list/2 = [1]
# [ 1 ];;
- : int list/2 = [1]

Seems like some state doesn't get updated in "toplevel expression" branch.

@trefis trefis reopened this Apr 12, 2019
@Octachron

This comment has been minimized.

Copy link
Contributor

commented Apr 12, 2019

Indeed, there is a problem with the end state of Printtyp.print_items if the last item is a type. This problematic end state is however overwritten by subsequent calls to Printtyp.print_items and is thus only observable with toplevel expressions that call directly Printtyp.tree_of_type_scheme.

Octachron added a commit that referenced this issue Apr 15, 2019
* Fix `Printtyp.print_items` final state 
* make `Printtyp.tree_of_type_declaration` more cautious when hiding the declared type within the body of the declaration.
* test
@Octachron

This comment has been minimized.

Copy link
Contributor

commented Apr 15, 2019

Fixed by #8613 .

@Octachron Octachron closed this Apr 15, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.