We from the Scala team at Lightbend have decided to take some time this summer to work on usability improvements that are always falling through the cracks while we’re busy working on the hard features of the next Scala release. Here is a summary of our project proposals.

REPL usability improvements

@som-snytt already implemented the JLine 3 upgrade (https://github.com/scala/scala/pull/8036) which gives multi-line history and editing. We are planning to add further improvements (many of them pioneered by Ammonite and/or the Dotty REPL) on top of this, for example syntax highlighting and importing library dependencies.

Roundtable: Unit Testing Library

We would like to work together with the community and maintainers of testing libraries to provide a zero-dependency unit testing library that ships with Scala releases, i.e., not as an external dependency. This library will be used in core projects (Scala, Scala.js) that currently have to fall back on JUnit. We also hope to find a common path forward to overcome some of the fragmentation in testing styles and libraries that is currently present in the Scala community.

Preprocessor

There are situations where conditional compilation would be quite handy, for example when cross-building a project against multiple Scala versions. This proposal introduces a preprocessor into the Scala compiler so that no changes to the build toolchain is required.

Configurable and Suppressible Warnings

The Scala compiler issues helpful warnings, for example when comparing unrelated types. Additional checks and warnings can be enabled with -Xlint, the -Werror flag turns all warnings into errors. In reality, not all warnings can always be eliminated: for example, cross-building may require using a deprecated API. This proposal introduces compiler flags to selectively promote or silence compiler warnings. It also adds support for suppressing warnings locally.

Discussions

The projects listed above are being discussed on their respective scala-dev ticket. As always, we welcome and encourage contributions and feedback.

If you have a usability project in mind that is not being discussed currently, feel free to mention it here. And of course, we’d be thrilled if you’re motivated to join the usability summer with your own project!

There shouldn’t be but it’s unlikely that anyone has tested it with a million options before.

If Preprocessor is used for cross-building against libraries the amount of options will be unpredictable.

Any individual preprocessor option would currently require at least one source folder, possibly more if you need different sources for combinations of various config options. I’m sure scalac can deal with more config options than you can deal with source folders.

In this topic I’d like to discuss concrete ideas to get better error message reporting into Scalac. @SethTisue has told me the Scala team at Lightbend is looking forward to getting this contribution from the Community, and so I’d like to gauge some feedback on this front.
I believe there is consensus at both the Scala Center and Lightbend about the importance of this feature. For example, @adriaanmhas briefly talked about it as one of the goals for Scala 2.13. As this topic has recently been …

This is an improtant topic that we’d love to see moving forward, but it just didn’t make it to our list this time.

And yes, of course error and warning messages are related to configurable and suppressable warnings. The proposal for configurable warnings is already non-trivial, so I decided to keep improvements to the actual messages separate.

However, maybe that’s not so simple. Implementing configurable warnings will require some refactorings in the compiler’s reporting facilities. If we’re doing this work, it might make sense to first think of a better internal representation for errors. We’ll see and keep that in mind.

I’m sure scalac can deal with more config options than you can deal with source folders.

Thanks, I have understood logic. And it can be undeniable for
libraries which are distributed by binary code.

But Mono-repositories and sharing by source code can be more useful for end applications or ERP decisions.
For example we have about 1000 function points in our old applications(not scala).
we currently use reflection for that purpose.
Such amount of combinations(point*module_version) is quite difficult to manage. And even if the compiler can support such amount of options. It is a leaky abstraction for that purpose.
Of course they always can say just don’t use it such way.
If it is so I will sorry. I think string comparison and primitive logical operations is not so hard to implement. At least it is supported by most languages which I know, for example gcc,plsql, etc

However, maybe that’s not so simple. Implementing configurable warnings will require some refactorings in the compiler’s reporting facilities

I believe this will also require changes in implementors of Zinc’s Reporter in build tools because pretty much every build tool implements its own, so this change might also need to move in tandem with build tools.

The idea is brilliant. It will help getting a foothold into corporate environments. Particularly in those with multinational development teams.The installers are often different than the users. More importantly it will simplify the auditing processes. The fewer moving parts, the less hostile people will be to new software.

A few suggestions on the installer.

Provide a bootstrapping SBT. One that includes all the language libraries (xml,parser) by default.

Two bootstrappers. One that includes the developer environment (compiler, testing tools, repl) and one for installing scala application (no compiler, testing tools).

If possible, just download a single complete runtime sbt bootstrap in a single jar. If a bat/bash/brew script is involved, all three should be in the single environment. File. Ideally, java -jar would be the only thing in the files. A fourth PDF or simple .html README file would be all that the bundle would include.

The sbt should be self updating (or skip more gracefully). Hopefully the single file installer should remain stable 1.3.1, 1.3.2, … allowing the bootstrapper to to update these minor version.

Ideally, the bootstrapper wouldn’t’ be a complete sbt. That’s just a want.

The sbt bootstrap should install with no user input by default. Perhaps a -interactive-install for people that want to be asked question like “where to install.”

The bootstrap installer should not be the runtime sbt. E.g. in can be run from download/tmp and deleted after the install. Or squirreled away to be rerun later (update,uninstall).

A question. If the parse & xml libraries are optional, how will persistence be handled?

Desire. sbt should be able to correctly update a pom, even a large complex existing pom. And pull dependencies from a pom.

I’ll chip in my 2c and say that improved compile errors should definitely be on the list, and probably affect more people in a more substantial way.

Things like a preprocessor are definitely advanced features, while a builtin unit test framework or tweaked distribution is “nice” but I don’t think a huge deal. In comparison, compile errors are front-and-centet in everyone’s experience trying to use Scala. Even simple things like colorizing the different parts of an error message using ANSI colors would be a huge boost in usability

It’s the first place I send those who are interested in playing with Scala without having to go through a PhD in understanding the Scala ecosystem before getting to play with a Scala REPL. However, being unable to see the resulting types with “Save” degrades the experience the instant they hit a weird type edge case…which is very quickly in Scala 2.

What I mean is, wouldn’t it be better to first do the things that have been planned for 2.14, many of which are critical for the Dotty transition, and then see how much extra time there is? Or do these proposals not affect that somehow? Or are they just higher priority?

The idea is to first let the dotty features bake a little longer before back porting them. We also still need to (collectively) decide which ones to back port in the first place. The other big work package is to iron out, implement and test the compatibility story – my preference is to start with that.