You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This might be classified as a regression or a feature request, depending on the extent to which REPL feature- and option-parity are goals. If it's deemed a feature request, I'm content to close this with reference to lampepfl/dotty-feature-requests#131, though I suspect its broad scope will need to be broken down for actions to progress.
The Scala 2 REPL got a lot of usability love particularly in the last couple of years or so, as I've begun to use Scala 3 I've felt the REPL as a step back in a few ways. (There are doubtless many improvements too, my anecdote isn't to complain as much as to color what parity might matter to people).
Compiler version
3.0.0
Minimized code
$ scala -i ~/.config/scala/replinit.scala
Output
bad option '-i' was ignored
1 warning found
Error: No main methods detected in script /Users/ches/.config/scala/replinit.scala
Expectation
REPL started with definitions loaded from file, as in Scala 2.
In my case, I emulate rc-style loading of some utility definitions for ad hoc REPL sessions via a scala wrapper script like this:
With an installation method that keeps the trusty old scala and scalac executable names for the Scala 3 tools, this is especially unfortunate. A workflow of switching tool versions in my shell environment, e.g. with sdkman, is broken with my wrapper.
It's perhaps worth noting that Ammonite has an analogous feature in the form of its user predef.sc—I even share my definitions between Ammonite and scala, with a snippet like this:
depending on the extent to which REPL feature- and option-parity are goals
It's not a goal, and it's not something anyone is actively working on (contributions welcome!), so a feature request is more appropriate than an issue indeed, feel free to add more details to lampepfl/dotty-feature-requests#131
This might be classified as a regression or a feature request, depending on the extent to which REPL feature- and option-parity are goals. If it's deemed a feature request, I'm content to close this with reference to lampepfl/dotty-feature-requests#131, though I suspect its broad scope will need to be broken down for actions to progress.
The Scala 2 REPL got a lot of usability love particularly in the last couple of years or so, as I've begun to use Scala 3 I've felt the REPL as a step back in a few ways. (There are doubtless many improvements too, my anecdote isn't to complain as much as to color what parity might matter to people).
Compiler version
3.0.0
Minimized code
$ scala -i ~/.config/scala/replinit.scala
Output
Expectation
REPL started with definitions loaded from file, as in Scala 2.
In my case, I emulate rc-style loading of some utility definitions for ad hoc REPL sessions via a
scala
wrapper script like this:With an installation method that keeps the trusty old
scala
andscalac
executable names for the Scala 3 tools, this is especially unfortunate. A workflow of switching tool versions in my shell environment, e.g. with sdkman, is broken with my wrapper.It's perhaps worth noting that Ammonite has an analogous feature in the form of its user
predef.sc
—I even share my definitions between Ammonite andscala
, with a snippet like this:The text was updated successfully, but these errors were encountered: