Add classification of language features to docs #6010
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
odersky
changed the title
nafg
reviewed
Mar 3, 2019
|
|
||
| In our experience, macros and changes in type and implicit argument inference together cause the large majority of problems encountered when porting existing code to Scala 3. The latter source of problems could be addressed systematically by a tool that added all inferred types and implicit arguments to a Scala 2 source code file. Most likely such a tool would be implemented as a Scala 2 compiler plugin. The resulting code would have a greatly increased likelihood to compile under Scala 3, but would often be bulky to the point of being unreadable. A second part of the rewriting tool should then selectively and iteratively remove type and implicit annotations that were synthesized by the first part as long as they compile under Scala 3. This second part could be implemented as a program that invokes the Scala 3 compiler `dotc` programmatically. | ||
|
|
||
| Several people have proposed such a tool for some time now. I believe it is time we find the will and the resources to actually implement it. |
There was a problem hiding this comment.
Maybe one approach to this would be:
- As stated, a tool that rewrites all inferred types to explicitly annotated types, but for both scala 2 and scala 3
- Use your VCS to record the result of running this both on Scala 2 and 3, and compare the results. Perhaps a merge tool with the right inputs would be a good way to streamline the process of reverting all identical added types, and highlighting the cases where they were not identical. For instance if you would have two branches where the first commit has the respective types and the next commit does not, it might find a conflict between a change A->C vs. B->C (where C is no explicit type, and A and B are the respective generated explicit type). On the other hand, wherever the generated types are the same, there would be no conflict and it would successfully apply the diff reverting to non-explicit types. Ideally this step would also be scripted, but it's probably just a few git commands.
Of course, you would have to ensure that there aren't red herrings. For instance you might need to output dotty type intersections using with, and use the same logic for when to output types in infix format.
I'm not sure enough of the mechanics of git merge conflicts, but this might simplify things a lot, at least for implementers.
There was a problem hiding this comment.
That's an interesting technique. I had not thought of using a merge conflicts to pinpoint problems.
Btw I set out to write this document to have some data as a basis for replying to your post on Scala Contributors. I am now too tired to write a coherent reply, but will do so tomorrow.
There was a problem hiding this comment.
Yeah I figured 😀
It's definitely appreciated!
propensive
reviewed
Mar 3, 2019
|
|
||
| This document provides an overview of the features proposed for Scala 3 with the aim to facilitate the discussion what to include and when to include it. It classifies features into seven categories: Essential foundations, simplifications, restrictions, dropped features, changed features, new features, and features oriented towards meta-programming with the aim to replace existing macros. | ||
|
|
||
| Each feature group contains sections classifying the status (i.e. relative importance to be a part of Scala-3, and relative urgency when to decide this) and the migration cost |
| author: Martin Odersky | ||
| --- | ||
|
|
||
| This document provides an overview of the features proposed for Scala 3 with the aim to facilitate the discussion what to include and when to include it. It classifies features into seven groups: Essential foundations, simplifications, restrictions, dropped features, changed features, new features, and features oriented towards meta-programming with the aim to replace existing macros. |
There was a problem hiding this comment.
It looks like it's now eight feature groups, not seven since "Changes to Type Checking and Inference" is included.
|
@propensive I merged this too fast. A new open version of the PR is at #6011. |
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.
No description provided.