-
-
Notifications
You must be signed in to change notification settings - Fork 415
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
Change to Steed's model of subtyping #3643
Change to Steed's model of subtyping #3643
Conversation
@@ -878,6 +889,53 @@ bool cap_view_lower(token_id left_cap, token_id left_eph, | |||
return true; | |||
} | |||
|
|||
bool cap_safetomove(token_id into, token_id cap, direction direction) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Rearranged code. No changes here
bool cap_safetomove(token_id into, token_id cap, direction direction) | ||
|
||
|
||
static ast_t* modified_cap_single(ast_t* type, cap_mutation* mutation) | ||
{ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Related to the above, I believe that the Git diffing algorithm has decided that this was derived from the cap safe_to_move above, so I would recommend not attempting to make sense of the diff and just looking at the raw code
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In any case, this is only used right now for the unisolation bit. More code can be made to use this, but that starts bringing up the scope (as there's also bugs caused by the way that some of those are implemented today)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good other than these small quibbles:
Noting that f92d601 may still not be correct with how we use the bounds, since it allows |
Once tests pass, this will be good to go, but we also need to update the tutorial's subtyping section and talk about error messages here. Still looking at package/stdlib updates |
Current question: what's the expected behavior for https://github.com/ponylang/ponyc/pull/3643/files#diff-de4b55849bafa987e2a3f3cd5f61edbced75be7d892d847d7beef4e9f9fcbeb5R460 These were the examples which were in tail position that was not exactly the last expression of a function. Should this sort of case be supported automatically? Perhaps it may be sufficient for now to support the easiest cases explicitly and later a more complete rule. |
Hi @jasoncarr0, The changelog - fixed label was added to this pull request; all PRs with a changelog label need to have release notes included as part of the PR. If you haven't added release notes already, please do. Release notes are added by creating a uniquely named file in the The basic format of the release notes (using markdown) should be:
Thanks. |
@jemc @jasoncarr0 i put a "fixed" label on this as it fixes a bug, however, maybe "changed" would be better. |
I do think some release notes are in order either way. |
@@ -139,6 +139,7 @@ bool is_method_result(typecheck_t* t, ast_t* ast) | |||
case TK_IF: | |||
case TK_WHILE: | |||
case TK_MATCH: | |||
case TK_IFDEF: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are there any other cases known missing from this function?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Referencing treecheckdef.h
, here are things I'm not seeing in this function that probably should be here:
TK_FOR
- the first two children are part of iterator declaration, and should return false hereTK_WITH
- the first child should return falseTK_REPEAT
- the second child (the condition) should return false
Removed the do not merge label since it was originally due to needing the tutorial updates. ponylang/pony-tutorial#449 should be merged whenever this is released |
When this is merged, ponylang/pony-tutorial#449 should be added to the current open release issue as something to be merged after the release. |
@jemc @jasoncarr0 are we ready to merge this sucker? |
@SeanTAllen I believe we are |
@jasoncarr0 is the initial commit comment good for when this gets squashed? do you want to squash and update the commit comment? otherwise i can squash it only keeping the initial comment. let me know which you prefer to do. |
Could you clarify which comment you're referring to as the initial comment @SeanTAllen ? I'm guessing I should just squash myself. I would think "Change to Steed's model of subtyping" or "Change to Steed's model of subtyping to fix return subtyping checks" would be sufficient as the commit |
I think the commit comment needs a why and what for general guidance. This is a change that touches a lot of places and for future history I think its important to have a commit comment that someone can use to understand it. For example, linking to where the steed work can be found and other relevant details. Basically "release notes" but pony developer focused rather than pony user. |
The original notion of subtyping in Pony combined subtyping and aliasing simultaneously (K1 <= K2 if K1^ could be coerced to K2). This is reasonable for many checks, which used aliasing already, but this wasn't sufficient for some subtyping checks (most notably return subtyping, where we do not alias a priori) and as a result, the subtyping used for return types was unsound, allowing an `iso` expression (Not `iso^`) to be coerced to any cap, such as creating a `val` reference while the `iso` was still around. This change decouples the two, using the subtype ordering for capabillities which was presented in George Steed's Masters thesis: "A Principled Design of Capabilites in Pony" Primarily, this means that most cases where aliasing were required before now check `K1 <= K2^`, whereas before it was often `!K1 <= K2` Importantly, this now means that subtyping can be checked without aliasing by checking that `K1 <= K2`. Some standard library methods had to be given weaker types due to the improper return type checks. It may be possible to re-strengthen these checks with some unsafe code, if it is genuinely sound to do so. In addition, the tail expression code was strengthened to handle some cases which were not handled prior. These likely did not arise due to the incorrect return subtyping checks, but are now necessary to auto-consume.
af4a2c8
to
ffac258
Compare
Looks good @jasoncarr0. Awesome work. Thanks. |
Most individual commits have a long comment describing what they do.
Notably, had to weaken the type of two map methods as they were incorrect for the implementation that they had (and it should be reasonably obvious I hope).
We will also need to ensure that documentation correctly disambiguates between
iso
andiso^
when talking about subtyping, as otherwise the error messages may be quite confusing (iso
is not a subcap ofref
). This is painfully unintuitive with current docs/cap-naming, but that unintuitiveness was exactly what got us into this unsound subtyping mess.Fixes #1964
Updated subtyping table: