Make given clauses come last
#6513
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
So far pathTo(span) would only guarantee to return the path to the closest tree enclosing `span` if trees were non-overlapping. This is property does not hold for typed trees, yet `pathTo` is called from `Interactive` on such typed trees. This commit makes `pathTo` work correctly also for overlapping trees.
With given coming last, some of the no-overlaps and in-order position checks have to be weakened. But with the more generalized pathTo implementation, non-overlapping and in-order is not really needed anymore.
They printed as normal arguments before.
The previous syntax was unparseable without major contortions in the Parser.
Can do it now that we have a full bootstrap.
These were printed as old-style implicit parameters before. This is in preparation for merging it with `Implied`. We already compensate for it when printing modifiers by eliding it when it appear with `Param`.
Synthesized creator expressions for classes passed all parameters as normal arguments. This works no longer with `given` clauses. We have use `given` arguments for those.
We now forbid given clauses followed by normal parameter clauses.
besides the syntactic awkwardness, there's also the problem
of eta expansion. Example:
```
trait Universe { type T }
def f given (u: Universe) (x: u.T)
```
How should we tea expand `f`? The usual algorithm would give:
```
(x: u.T) => (f given the[Universe])(x)
```
but that's ill typed, since `u` is not defined on the outside.
dottybot
reviewed
May 14, 2019
There was a problem hiding this comment.
Hello, and thank you for opening this PR! 🎉
All contributors have signed the CLA, thank you! ❤️
Commit Messages
We want to keep history, but for that to actually be useful we have
some rules on how to format our commit messages (relevant xkcd).
Please stick to these guidelines for commit messages:
- Separate subject from body with a blank line
- When fixing an issue, start your commit message with
Fix #<ISSUE-NBR>:- Limit the subject line to 72 characters
- Capitalize the subject line
- Do not end the subject line with a period
- Use the imperative mood in the subject line ("Add" instead of "Added")
- Wrap the body at 80 characters
- Use the body to explain what and why vs. how
adapted from https://chris.beams.io/posts/git-commit
Have an awesome day! ☀️
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
We now forbid given clauses followed by normal parameter clauses.
besides the syntactic awkwardness, there's also the problem
of eta expansion. Example:
How should we eta expand
f? The usual algorithm would give:but that's ill typed, since
uis not defined on the outside.(only last commit is new)