Implement initial and cleanup commands as well as value bindings for REPL

[felixmulder]

https://github.com/dotty-staging/dotty/blob/812f141ba97e224168fc3bf91a6401c5dd349ce8/sbt-bridge/src/xsbt/ConsoleInterface.scala#L22-L39

[3shv]

While I was working on this, few doubts popped up.

1. Can we assume initial and cleanup commands are always parsed successfully?
   -- If yes, probably we can make case class Silent extends Parsed
2. If not, is the case class Silent always one of Parsed, SyntaxErrors, Newline, SigKill, Command?
   Hope I made sense.

[felixmulder]

You're making sense :)

1. No
2. Yes

One way to do this is to say:

case class Silent(underlying: ParseResult) extends ParseResult {
  require(!underlying.isInstanceOf[Silent])
}

that way we can unpack it to the underlying result.

A more type safe way to do this is to introduce a marker trait extending ParseResult that denotes something concrete e.g:

          ParseResult
               |
   +-----------+-----------+
   |                       |
Silent             ConcreteParseResult
                           |
                           +--------- Parsed, SyntaxErrors, NewLine etc

And then making Silent be:

case class Silent(underlying: ConcreteParseResult) extends ParseResult

Perhaps there's a better name than concrete though 😄

[3shv]

Thanks for the help. I've submitted a WIP PR, to check if I'm going in right direction. If I understood marker traits correctly, I need to declare a trait, say Concrete and attach it to all Parsed, SyntaxErrors, NewLine etc right?
Say,
case class Parsed(...) extends ParseResult with Concrete

Also I'm getting this warning, even though I am unpacking the inner object and required Silent can't inherit Silent
[warn] It would fail on the following input: Silent(_) [warn] parseResult match {

[SzymonPajzert]

Is this feature still requested? As I understand, it wasn't implemented in the master in the end.

[Blaisorblade]

Is this feature still requested?

Yes.

As I understand, it wasn't implemented in the master in the end.

We didn't stop liking the feature. The help wanted label means "outside contributions welcome" ;-).

[SzymonPajzert]

I have implemented the changes, they seem to be much easier after refactoring, but I haven't added yet any tests to check the results. Where should I put them?

[Blaisorblade]

Under sbt-dotty/sbt-test/ we have tests that use sbt-scripted (https://www.scala-sbt.org/1.0/docs/Testing-sbt-plugins.html); sbt-dotty/sbt-test/sbt-dotty/example-project/test seems closest, and 061fdb1 and f503ad3 seem about it (but I'm not sure on the status, and I think @allanrenucci is on vacation).
EDIT: but while we wait, feel free to experiment with them!