Dotty: Some REPL suggestions

Created on 29 Apr 2019  路  3Comments  路  Source: lampepfl/dotty

I have recently worked a little bit with Scala鈥檚 default shell and ammonite, and I find them both severely lacking compared to languages designed for interactivity. (Ammonite is much better than the default though.)

Specifically, I think these two points are of severe importance:

  • Being able to see the documentation (and possibly the source of) methods and classes, etc. (Ammonite tries to provide this feature through its source builtin method, but it doesn鈥檛 really work.)

  • Being able to embed the REPL in the code, like IPython.embed(). (Ammonite does support launching a shell with the dependencies of the project included, which is good, but not enough.)

I believe having a good REPL experience is very essential for a language that markets itself as scalable; REPLs are extremely helpful when working with new APIs and doing experimentations.

Most helpful comment

Embedding a REPL that preserves everything in scope is a challenge, various transformations done during compilation means that what is in scope in the source code might not be in scope any more at runtime, and even ignoring that, it's not possible to use JVM reflection to find out what's in scope at runtime. So the only way to do something like that is with a special compile-time transformation. I've been working on something like this for the purpose of evaluating Scala expressions in the debugger, and the same technique might also work for REPL embedding, but no promise!

All 3 comments

Being able to see the documentation (and possibly the source of) methods and classes, etc.

Already implemented :). https://github.com/lampepfl/dotty/pull/4669 Though it doesn't work with external Java and Scala 2 projects yet since that requires non-trivial build tool integration to get the sources to be able to parse the documentation.

Being able to embed the REPL in the code, like IPython.embed().

The Scala 2 REPL can do that. Dotty also has some support for that, see https://github.com/lampepfl/dotty/pull/5686 for example.

I believe having a good REPL experience is very essential for a language that markets itself as scalable; REPLs are extremely helpful when working with new APIs and doing experimentations.

Agreed! See also https://contributors.scala-lang.org/t/proposal-simplifying-the-scala-getting-started-experience/2978/2 for some of my thoughts on that.

I'll be closing this issue, but if you have other ideas feel free to share them on http://contributors.scala-lang.org/ or http://gitter.im/lampepfl/dotty

@smarter Thanks!
One thing that still seems missing or at least not well documented is how to embed the repl without losing the current scope. Just some random repl without the in-scope variables isn鈥檛 that useful.

PS: Gitter notifications don鈥檛 seem to work for me, and I find the experience generally buggy, that鈥檚 why I have avoided it.

Embedding a REPL that preserves everything in scope is a challenge, various transformations done during compilation means that what is in scope in the source code might not be in scope any more at runtime, and even ignoring that, it's not possible to use JVM reflection to find out what's in scope at runtime. So the only way to do something like that is with a special compile-time transformation. I've been working on something like this for the purpose of evaluating Scala expressions in the debugger, and the same technique might also work for REPL embedding, but no promise!

Was this page helpful?
0 / 5 - 0 ratings