Skip to content

Some REPL suggestions #6394

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

Closed
NightMachinery opened this issue Apr 29, 2019 · 3 comments
Closed

Some REPL suggestions #6394

NightMachinery opened this issue Apr 29, 2019 · 3 comments

Comments

@NightMachinery
Copy link

I have recently worked a little bit with Scala’s 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’t 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.

@smarter
Copy link
Member

smarter commented Apr 30, 2019

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

Already implemented :). #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 #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 smarter closed this as completed Apr 30, 2019
@NightMachinery
Copy link
Author

@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’t that useful.

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

@smarter
Copy link
Member

smarter commented Apr 30, 2019

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants