Description
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:
#!/bin/sh
SCALA=${SCALA:-/usr/local/bin/scala}
if [ "$#" -eq 0 ] && [ -r ~/.config/scala/replinit.scala ]; then
exec "$SCALA" -i ~/.config/scala/replinit.scala -Dscala.color=true -deprecation -Xlint:-unused,_
else
exec "$SCALA" "$@"
fi
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:
try repl.load.exec(ammonite.ops.home/".config"/'scala/"replinit.scala")
catch { case _: Exception => println("=== replinit defs not loaded! ===") }