Skip to content
Merged
Show file tree
Hide file tree
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 Jan 30, 2019
8201ae1
Disallow empty implicit parameter sections
odersky Jan 30, 2019
5dd0a11
Avoid spurious error spans
odersky Jan 30, 2019
2baba5b
Change syntax of implicit function types and closures
odersky Jan 30, 2019
f324ea5
Fix new tests after merge
odersky Jan 30, 2019
319d874
Fix new tests after changes
odersky Jan 30, 2019
1c90ec2
Syntax change: `inferred for` instead of `instance of`
odersky Jan 30, 2019
af796f7
Reorganize docs to consolidate all implicit changes
odersky Jan 30, 2019
1e47e5c
Rename "implicit function type" to "query type"
odersky Jan 31, 2019
e792c88
Cleanups
odersky Jan 31, 2019
3bc0547
Renaming "instance of" -> "implied for"
odersky Jan 31, 2019
e2f1299
Tweaks to wordings in docs
odersky Jan 31, 2019
53f00ae
Implied Conversion -> Implicit Conversion
odersky Feb 1, 2019
a1ffafc
Rename internals to new terminologu
odersky Feb 1, 2019
c04e041
Allow toplevel definitions in syntax and parsing
odersky Dec 5, 2018
031532d
Desugar toplevel definitions
odersky Jan 19, 2019
61564ba
Treat toplevel objects as package objects
odersky Jan 20, 2019
359b80f
Make toplevel wrappers unexpressible as normal objects
odersky Jan 20, 2019
5b90688
Docs
odersky Jan 20, 2019
b069f8d
Change scheme to name package object wrappers
odersky Jan 21, 2019
ab0ea23
Allow toplevel implicits
odersky Jan 23, 2019
a105398
Disallow toplevel statements other than definitions
odersky Jan 23, 2019
97f06e0
Refine condition for printing package objects
odersky Jan 23, 2019
160fe40
Detect and report double definitions between toplevel files
odersky Jan 23, 2019
0aab6e4
Test source compiled twice
odersky Jan 23, 2019
e3a24d3
Fix package object printing
odersky Jan 23, 2019
e9dd68e
Add test for ambiguous overloads
odersky Jan 24, 2019
a4950d0
Add illegal cyclic reference test
odersky Jan 24, 2019
be77747
Add legal cyclic reference test
odersky Jan 24, 2019
560d608
Fix illegal cyclic reference test
odersky Jan 24, 2019
f9aff3e
Allow toplevel opaque types
odersky Jan 24, 2019
280744e
Update docs
odersky Jan 24, 2019
444cffa
Be more careful where we fill in missing companion objects
odersky Jan 24, 2019
e946936
Generalize member computation for package members
odersky Jan 24, 2019
67bcab2
Try various combinations of toplevel definitions
odersky Jan 24, 2019
1cb7cb1
More implicit and overloading tests
odersky Jan 24, 2019
205972c
Update docs
odersky Jan 24, 2019
44877bd
Add spec and test for private toplevel definitions
odersky Jan 24, 2019
8278568
Make toplevel privates package private
odersky Jan 24, 2019
572471f
Change scheme to widen toplevel private
odersky Jan 24, 2019
a789cdd
Skip package objects in Typer#findRef
odersky Jan 25, 2019
e81f52d
Revert #3735: Allow accesses to private package members from nested
odersky Jan 25, 2019
7b018de
Fix test check file
odersky Jan 25, 2019
4ce52d0
Tweak to prefix printing
odersky Jan 25, 2019
d874964
Try with a final modifier
odersky Jan 25, 2019
ed5304e
Address review comments
odersky Feb 2, 2019
db36559
Avoid illegal characters in package objects
odersky Feb 2, 2019
537f80d
Add separate compilation test case for #3339
odersky Feb 2, 2019
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
Prev Previous commit
Next Next commit
Update docs
and fix test comment
  • Loading branch information
odersky committed Feb 1, 2019
commit 280744e40b4a19f012f8ca941bca185e210eca4b
10 changes: 8 additions & 2 deletions docs/docs/reference/dropped-features/package-objects.md
Original file line number Diff line number Diff line change
Expand Up @@ -25,6 +25,12 @@ Package objects are no longer needed since all kinds of definitions can now be w
def (x: C) pair (y: C) = (x, y)
}
```
There may be several source files in a package containing such toplevel definitions, and source files can freely mix toplevel value, method, and tyoe definitions with classes and objects.
There may be several source files in a package containing such toplevel definitions, and source files can freely mix toplevel value, method, and type definitions with classes and objects.

The compiler generates synthetic objects that wrap toplevel statements that are not imports, or class or object definitions. If a source file `src.scala` contains such toplevel statements, they will be put in a synthetic object named `src$package`. The wrapping is transparent, however. The definitions in `f` can still be accessed as members of the enclosing package.
The compiler generates synthetic objects that wrap toplevel definitions falling into one of the following categories:

- all pattern, value, method, and type definitions,
- implicit classes and objects,
- companion objects of opaque types.

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 in val _ = println("Hello") is trivial

Copy link
Contributor Author

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.

Copy link

@lihaoyi-databricks lihaoyi-databricks Jan 25, 2019

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, scala command, 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 a Hello.scala. That would move Scala closer to the Python getting started experience print("Hello World"), I think in a good way.

Copy link
Contributor

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).

Copy link
Contributor

@soronpo soronpo Jan 25, 2019

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 App instead of just writing the main code in the file?

Copy link
Contributor

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: .sc files are entrypoints, .scala files are library files. .sc is already supported by a lot of tools, editors such as IntelliJ, etc. which understand those files to allow top-level expressions.


If a source file `src.scala` contains such toplevel definitions, they will be put in a synthetic object named `src$package`. The wrapping is transparent, however. The definitions in `src` can still be accessed as members of the enclosing package.
8 changes: 4 additions & 4 deletions tests/pos/toplevel-opaque/Test.scala
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)
}