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

A parent "feature request" for a serie of FR about printing type variables #5444

Closed
vicuna opened this issue Dec 23, 2011 · 2 comments
Closed
Assignees

Comments

@vicuna
Copy link

vicuna commented Dec 23, 2011

Original bug ID: 5444
Reporter: pilki
Assigned to: @garrigue
Status: closed (set by @xavierleroy on 2012-09-25T18:07:21Z)
Resolution: fixed
Severity: feature
Platform: all
OS: all
OS Version: all
Category: ~DO NOT USE (was: OCaml general)
Parent of: #5445 #5446 #5447 #5448 #5449 #5450

Bug description

This feature request is used as a parent for a serie of feature requests (or maybe just comments) about the printing of type variable.

In the trunk, when you type
let f (x:'foo) = x
the inferred type is now 'foo -> 'foo

But this still suffers a certain number of limitations that are reported in subsequent request

(Disclaimer: I talked a bit about that over email with Jacques Garrigue, and I know that some of this "features" are not worth the time. I still report them here for futur references)

@vicuna
Copy link
Author

vicuna commented Dec 24, 2011

Comment author: @garrigue

Thank you for making it look like I'm doing lots of work :-)
But maybe you didn't need to split to such detail.
Basically all the behaviors you describe come from the fact variable names are not inherited upon instantiation.
In some cases (single identifier at toplevel and (type u) notation) I agree there is a problem, but in other cases I'm basically not convinced that inheriting names would not be that helpful (and would have to be done with care).

To be precise, the main goal of named type variables was to make error reports clearer: if you have written a variable name, either in an expression or a type definition, it should be used when reporting errors inside that expression or type definition. If you find a case where it is not used, then this is a bug.

@vicuna
Copy link
Author

vicuna commented Dec 28, 2011

Comment author: @garrigue

All children are resolved.
Do not close for future reference.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants