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

Better type propagation within object literals #7159

Closed
vicuna opened this issue Mar 1, 2016 · 3 comments
Closed

Better type propagation within object literals #7159

vicuna opened this issue Mar 1, 2016 · 3 comments

Comments

@vicuna
Copy link

vicuna commented Mar 1, 2016

Original bug ID: 7159
Reporter: @alainfrisch
Assigned to: @garrigue
Status: acknowledged (set by @garrigue on 2016-03-02T00:43:12Z)
Resolution: open
Priority: low
Severity: feature
Target version: undecided
Category: typing
Monitored by: @hcarty

Bug description

Compare:

# (("abc", 42) : (int * int));;
Characters 2-7:
  (("abc", 42) : (int * int));;
    ^^^^^
Error: This expression has type string but an expression was expected of type
         int

and

# (object method x = "abc" method y = 42 end : <x: int; y: int>);;
Characters 1-42:
  (object method x = "abc" method y = 42 end : <x: int; y: int>);;
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Error: This expression has type < x : string; y : int >
       but an expression was expected of type < x : int; y : int >
       Types for method x are incompatible

It could be useful (for error messages and type-based selection) to propagate types from the context to the method bodies for an object literal.

In case of an immediate annotation on the object literal, one can already put the constraint on "this":

# object(_ : <x: int; y:int>) method x = "abc" method y = 42 end;;
Characters 39-44:
  object(_ : <x: int; y:int>) method x = "abc" method y = 42 end;;
                                         ^^^^^
Error: This expression has type string but an expression was expected of type
         int
@vicuna
Copy link
Author

vicuna commented Mar 2, 2016

Comment author: @garrigue

I see your point.
As you point out, it shouldn't be that difficult, since one should just propagate the expected type to the internal self-type.
However, code in typeclass is really hairy, so don't hold your breath.

@github-actions
Copy link

github-actions bot commented May 9, 2020

This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc.

@github-actions github-actions bot added the Stale label May 9, 2020
@garrigue garrigue removed the Stale label May 9, 2020
@github-actions
Copy link

This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc.

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