- Notifications
You must be signed in to change notification settings - Fork 1.1k
Allow toplevel definitions #5754
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
Merged
Merged
Changes from 1 commit
Commits
Show all changes
48 commits Select commit Hold shift + click to select a range
e17ded1 Use `given` for implicit parameters and arguments
odersky 8201ae1 Disallow empty implicit parameter sections
odersky 5dd0a11 Avoid spurious error spans
odersky 2baba5b Change syntax of implicit function types and closures
odersky f324ea5 Fix new tests after merge
odersky 319d874 Fix new tests after changes
odersky 1c90ec2 Syntax change: `inferred for` instead of `instance of`
odersky af796f7 Reorganize docs to consolidate all implicit changes
odersky 1e47e5c Rename "implicit function type" to "query type"
odersky e792c88 Cleanups
odersky 3bc0547 Renaming "instance of" -> "implied for"
odersky e2f1299 Tweaks to wordings in docs
odersky 53f00ae Implied Conversion -> Implicit Conversion
odersky a1ffafc Rename internals to new terminologu
odersky c04e041 Allow toplevel definitions in syntax and parsing
odersky 031532d Desugar toplevel definitions
odersky 61564ba Treat toplevel objects as package objects
odersky 359b80f Make toplevel wrappers unexpressible as normal objects
odersky 5b90688 Docs
odersky b069f8d Change scheme to name package object wrappers
odersky ab0ea23 Allow toplevel implicits
odersky a105398 Disallow toplevel statements other than definitions
odersky 97f06e0 Refine condition for printing package objects
odersky 160fe40 Detect and report double definitions between toplevel files
odersky 0aab6e4 Test source compiled twice
odersky e3a24d3 Fix package object printing
odersky e9dd68e Add test for ambiguous overloads
odersky a4950d0 Add illegal cyclic reference test
odersky be77747 Add legal cyclic reference test
odersky 560d608 Fix illegal cyclic reference test
odersky f9aff3e Allow toplevel opaque types
odersky 280744e Update docs
odersky 444cffa Be more careful where we fill in missing companion objects
odersky e946936 Generalize member computation for package members
odersky 67bcab2 Try various combinations of toplevel definitions
odersky 1cb7cb1 More implicit and overloading tests
odersky 205972c Update docs
odersky 44877bd Add spec and test for private toplevel definitions
odersky 8278568 Make toplevel privates package private
odersky 572471f Change scheme to widen toplevel private
odersky a789cdd Skip package objects in Typer#findRef
odersky e81f52d Revert #3735: Allow accesses to private package members from nested
odersky 7b018de Fix test check file
odersky 4ce52d0 Tweak to prefix printing
odersky d874964 Try with a final modifier
odersky ed5304e Address review comments
odersky db36559 Avoid illegal characters in package objects
odersky 537f80d Add separate compilation test case for #3339
odersky File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Update docs
and fix test comment
- Loading branch information
commit 280744e40b4a19f012f8ca941bca185e210eca4b
There are no files selected for viewing
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
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
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,6 +1,6 @@ | ||
| object Test { | ||
| val x: T[Int] = ??? //2 // error | ||
| val y: Int = 1 // x // error | ||
| val a: Int = T.f(x) // ok | ||
| val b: T[Int] = T.g(y) // ok | ||
| val x: T[Int] = ??? | ||
| val y: Int = 1 | ||
| val a: Int = T.f(x) | ||
| val b: T[Int] = T.g(y) | ||
| } |
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.
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.
What about side-effecting expressions like
println("Hello")? Those should work too right, since wrapping them inval _ = println("Hello")is trivialThere 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.
Yes, but the changes in parser do not support them. I am not sure we want to do this.
Uh oh!
There was an error while loading. Please reload this page.
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.
If the goal is to try and normalize the various Scala source file syntaxes as @smarter wants, we would need to do this since all the various Scala scripting syntaxes (Ammonite's
amm,scalacommand, Mill, SBT, worksheets, ...) all support top-level expressions like this.This would also potentially make getting started with Scala much simpler: you could write code in a file, and run the file (this would require straightforward changes in the launcher script). Hello world could literally be
println("Hello World")in aHello.scala. That would move Scala closer to the Python getting started experienceprint("Hello World"), I think in a good way.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.
I agree with @lihaoyi-databricks about the benefits. I remember my first scala experience where I could do stuff in REPL that are impossible when I write a scala file and compile it (and I don't mean redeclaring defs and vals, of course).
Uh oh!
There was an error while loading. Please reload this page.
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.
Maybe we should somehow separate the concept between an application and a library. Indeed a library shouldn't have side-effecting values, but an application, why not? Why to write an application we need to extend
Appinstead of just writing the main code in the file?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.
@soronpo one neat way to disambiguate "applications" or "entrypoints" with top-level code and "libraries" without top-level code would be the file extension:
.scfiles are entrypoints,.scalafiles are library files..scis already supported by a lot of tools, editors such as IntelliJ, etc. which understand those files to allow top-level expressions.