Skip to content
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

REPL: open up for extensibility #16276

Merged
merged 4 commits into from
Nov 17, 2022

Conversation

mpollmeier
Copy link
Contributor

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.

@SethTisue
Copy link
Member

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.

@mpollmeier
Copy link
Contributor Author

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.

@mpollmeier
Copy link
Contributor Author

ping - I was hoping this would get a review... any takers?

@lrytz
Copy link
Member

lrytz commented Nov 14, 2022

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.

@mpollmeier
Copy link
Contributor Author

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?

That's completely fine, I fully embrace traditional Scala spirit to evolve APIs rather than having things like java.util.Date around for decades :)

I'm also aware of SIP-46 which may make scala-repl-pp obsolete in the long run. If they manage to bring in the functionality without adding too many dependencies that would actually be great for everyone.

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.

@dwijnand
Copy link
Member

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".

Copy link
Member

@dwijnand dwijnand left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm ok with merging this, under the understanding that there are no guarantees attached.

@mpollmeier
Copy link
Contributor Author

ping everything is green - would be great if someone could merge this to ensure it's part of 3.2.2 - thank you!

@SethTisue
Copy link
Member

SethTisue commented Nov 17, 2022

(I believe the target version here would be 3.3.0, not 3.2.2. Point releases are supposed to only address regressions.)

@dwijnand dwijnand merged commit 3635303 into scala:main Nov 17, 2022
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

Successfully merging this pull request may close these issues.

4 participants