RFC: structured rendering and switching to ammonite's color palette. #17624
Conversation
* pprint dependencyTree: 3 jars weighing 360k in total * pprint 0.8.1: 150k * fansi 0.4.0: 102k * sourcecode 0.3.0: 108k * if it's too large, workaround could be to allow injecting something by configuration - it's using reflection anyway... * might make sense to factor repl out into a separate subproject... jline is probably also only needed for the repl, no?
e.g. `val res0: Int = 23`
My two cents about the colour palette: I prefer the current one :)
That said, highlighting types like you did looks good! |
|
Adding First of all, there's a general rule that the compiler itself must not have any dependencies on external scala projects. That would indeed require that the REPL gets moved to a separate module. But that might require a minor release (@Kordyjan please confirm) because it would be published as a separate artifact depending on Secondly, it seems that adding a transitive dependency on a particular version of |
|
The rule "the compiler itself must not have any dependencies on external scala projects" makes a lot of sense but is unfortunately already violated: see the scala3-compiler-3.3.0.pom which includes three jline dependencies which are only needed for the REPL. So, as stated in the description, we should separate out the repl as a subproject, which is actually a task that can be done separately from this proposal. |
|
Good point that we might be breaking some existing builds by bringing in License-wise that should be fine (it's MIT licensed), but I want to be very careful to not step onto anyones toes, so I'd kindly ask the maintainers. It also means that we have a larger codebase to maintain, e.g. future patches need to be reintegrated etc. Overall I'd say the benefits outweigh the costs though... thoughts? |
Java dependencies are fine. What we really need to avoid are Scala dependencies. |
|
The repl calls into scala 2 runtime for stringifying. I tried to improve semi-structured rendering for years, and I don't understand the resistance to change. Even the more recent effort to just doing ellipsis correctly to show truncation stalled. I would recommend improved decoupling. Those PRs were |
The current REPL's output rendering is suboptimal:
the color highlighting is based on the string representation, i.e. all type information is thrown away before we render the results. I.e. information such as product labels, type information etc. are lost.
The output isn't formatted for readability as users - ammonite does a much better job and also has a color palette that most users prefer
there's a few bugs, e.g. REPL gives stack overflow during too eager syntax highlighting, e.g. when multiplying string #16904
This attempts to fix the points above by using pprint for the rendering, while we still have instances rather than just the output string.
Current stock repl: no product labels, no formatting, different colors
This RFC:
pprintbrings in three additional jars weighing 360k in total.This is just an RFC to gather feedback - an incomplete list of things TBD:
replsubproject to isolate it fromscala3-compiler, e.g. to use the repl-only dependencies (jline, pprint) only for the REPLContext: I'm using https://github.com/mpollmeier/scala-repl-pp as breeding ground for enhancing the REPL. The idea is to not create a hard fork but to bring the parts that are useful for dotty back upstream.
Looking forward to your feedback!