REPL: open up for extensibility #16276
Conversation
|
scala-repl-pp looks very cool. Some of its features would probably be accepted as part of the stock REPL if submitted as individual pull requests, I imagine. |
|
I'm glad you like it! And I'd happily create PRs for bringing it's features into the stock REPL. Most of them rely on external dependencies (most notably coursier and pprint) though, so I'm not sure if that really flies. Simple stuff like "customize greeting, prompt and shutdown code" and "predef code - i.e. run custom code before starting the REPL - via string and scripts" would be no problem though. Anyway, this PR is really independent from that thought - we'd need these changes either way if we want to open up the door for scala-repl-pp or add similar enhancements into the stock REPL. |
|
ping - I was hoping this would get a review... any takers? |
|
This PR is making some "API" public that was not designed to be an extensible API; we did basically the same in Scala 2. I'm personally fine with that, but projects using this API should have a way to deal with breaking changes. We should not be forced to promise that the current API remains stable. How is that in your case? Maybe the next breaking change will be the introduction of an actual REPL interface :) Work in that direction in Scala 2.13: scala/scala#5903 I second the suggestion to submit REPL features directly here where possible; I understand that it's not possible for all features. |
That's completely fine, I fully embrace traditional Scala spirit to evolve APIs rather than having things like I'm also aware of SIP-46 which may make I'll create separate PRs to bring in the scala-repl-pp features that don't depend on community libraries. They partly rely on this PR, so it would be best to get this one in first. |
I think we can consider features that rely on community libraries too, with some graceful fallback behaviour. I'm thinking of something like "error: The ":coursier" command requires the coursier jar on the classpath". |
|
ping everything is green - would be great if someone could merge this to ensure it's part of 3.2.2 - thank you! |
|
(I believe the target version here would be 3.3.0, not 3.2.2. Point releases are supposed to only address regressions.) |
The Scala ecosystem has two major REPLs: the regular Scala REPL and Ammonite.
The former is intentionally kept low-key and simple: a concise and readable codebase, no bells and whistles, focusing on core Scala features.
Ammonite has a ton of features, but also a very complex build, leading to dependency tree issues and has many shortcomings in it's Scala 3 support, e.g. re extension methods.
Scala-CLI wraps up both and provides some additions, mostly via scripting, but doesn't add another REPL implementation.
IMO there is a gap in the middle, and we can fill it fairly easily: if we open up selected fields in the standard REPL implementation, we allow downstream builds to inherit the complete Scala support and build more features on top. This PR and the corresponding scala-repl-pp demonstrate that: runtime dependencies via maven coordinates, pretty printing, customized prompt and shutdown code, scripting with multiple
@main, predef code, server mode, ...It's heavily inspired by Ammonite and scala-cli, but is fundamentally simpler: the above features are implemented in only 700 lines of code. It's straightforward dependency tree allows users to embed it in their own builds, making their domains available in a customised REPL, while inheriting the full Scala REPL feature set.
The scala-repl-pp readme has more details and use cases. I published a custom scala3-compiler to maven central, so you can easily try it out.