Gedanken

What's new in Scala 2.10

Confirmed

Language

Library

Compiler

Maybe

Probably not

  • Removal of String (any2stringadd) and number implicits
  • Removal of the deprecated methods in List.

Weird things happening in Scala land ...

A few days ago, a new Scala Improvement Process website launched with a few more or less new proposals.

Athough the move itself was pretty surprising (at least for me), because it looks like a sign that the Scala team finally manages to get their act together community and contribution wise, the contents of the proposals itself left me deeply confused:

SIP-13 (Implicit classes) by Josh Suereth really has some merit (although the proposed syntax is misleading and wrong) but SIP-11 and SIP-12 (both by Martin Odersky) made me scratch my head.

While SIP-11 (String interpolation) proposes a redundant yet-another-way to build Strings, SIP-12 (Uncluttering Scala’s syntax for control structures) is more than just completely insane.

I really wonder what has happened that the highly respected founder of the language comes up with proposals on changing around the basic syntax of the most fundamental control structures of Scala without any actual gains or benefits a decade after its creation.

I'm pretty sure that everyone who would come up with one of these ideas on one of the mailing list would have qualified himself for T. Morris-sized rhetorical ass kick from our friendly mailing list population.

Let's just hope that SIP-12 gets shot down as fast as possible, but seeing that SIP-11 was included in the source tree before the proposal was even made, I'm not sure how much influence the community really has.

Thoughts about Units of Measurements

Features

  • Computations: 4s + 5s == 9s
  • Conversions
    between dimensions: 5m + 10cm == ...
    between metric systems: 5ft + 10cm = ...
  • Dimensions: 5m * 5m == 25m² || 10m/s * 1s == 10m || 10m² / 5m == 5m
  • Everything in combination!


Requirements

  • Static type safety of computations and conversions
  • Verification at compile-time
  • No performance penalty at runtime
  • No restriction on numeric types


Problems

  • How to express this in an extendable, user-friendly way?
    • Large signatures
    • Heavy boilerplate definitions


Questions

  • Is this possible without language extensions?
  • Are there any sacrifices possible without substantially reducing the usefullness?
  • If this is implemented via some compile-time-only construct (like Phantom Types), how will it compare to specialization?
  • Code generation necessary?


Discussion

  • Hard problem, with many non-compromisable requirements
  • Currently no support in Java's or Scala's Development Kit
  • Having core classes covering common ground is alwas desirable
    • consider Date&Time libraries as a potential consumer
    • consider Groups, Semigroups, Monoids, Rings as another area not covered in the SDK
  • Java failed twice (JSR-108/JSR-275) with a "library-only" approach
  • Scala's type system is much more powerful, but is it enough?
  • F# has special support build into the language, but is this approach acceptable for general-purpose language
  • IMHO some more generic support benefitting other areas would be desirable, e. g. Numeric[T]
  • Is it possible to ship with a feature set covering 99,9% of all user's requirements, making the issue of extendability much less pressing?
  • If the ugliness is only at the declaration site it is much more acceptable


References

  • F#: Language support for Units of Measurement
  • Frink: Special purpose language for unit calculations
  • Java: Failed standardization requests JSR-108/JSR-275

The days after JavaFX2

How can we go on?

  • Concentrate on scala-swing?
    • Documentation needs to be improved
    • How many scala-swing user do we actually have?
    • Some things just look out of place, like programming examples and flower pictures shipping with the production jar
    • Probably need to integrate third-party classes (e. g. MigLayout) to become a go-to language/library for UI development
  • Pick up other efforts?
    • Various efforts on SWT in the past: XScalaWT, others
    • QtJambi? Recent activity in QtScampi!
      • Looks interesting and seems  to work
      • Large parts of QtJambi are script-generated and maintained by others
      • We wouldn't be alone: Other JVM languages also want to use Qt.
  • Can we combine various classes/traits/infrastructure/approaches between different UI toolkits?
    • E. g. Publisher, Event handling and subscription, etc. ...

Thoughts about language design - The "Elvis operator"

In which language design scenarios could an "Evlis operator" make sense?

Let's consider langauges with the following design decisions:

Language A

  • No support for laziness
  • References can be null

⇒ It is not possible to implement an "Elvis operator" as a library and nulls are a common problem.

Considering ? might make sense here, we push the idea a bit further:
Why not introduce e. g. 3 different "dereference styles" while we're at it instead?

  • "." ≙ The method is pure (hard to guarantee). The method is guaranteed a) to return (no exceptions) and b) the return value won't be null.
  • "?" ≙ The method might return null. "?" could be described as a dereference operator "catching the NPE".
  • "!" ≙ The method might not return at all or might return null. "!" could be described as a dereference operator "handling every Exception/Throwable".

Consider the following change to Language A, lets call the result
Language B

  • null does not exist. (Just ignore for a moment the huge restrictions this would require regarding serialization, initialization and constructor design.)

⇒ ? doesn't make much sense, because the use case is missing.

Consider the following, different change to Language A, lets call the result
Language C

  • Support for laziness.

⇒ No need to add any special syntax rules to the language, everything can be implemented as a library.
⇒ ? doesn't make much sense.

Taking a completely different apporach ...

Would it make sense to  take a completely different approach and reduce/eliminate the usage of null, by making it possible to supply a "default" value for every class/type?

E.g. 0 for Int, "" for String, Nil for List, ...

Benefits:

  • It can lift many of the restrictions language B suffers
  • It is easy and would integrate "primitive" types much better (compared to languages which just say "well, everything is null, except ...")

Risks:

  • There are many use-cases where there is not a single "right" default type (not everything is an Monoid).
  • How does this work with inheritance and variance?
    • Inheritance-by-default won't always work and adds a considerable tax to sub-classing.
    • Annotations to control sub-classing behaviour? (Bad!)
  • How would an implementation look like?
    • Some special (probably non-inherited) method/field which just has to be defined in the class/companion object?
      • plus an marker interface (think Serializable)? Or more like Cloneable?
    • Special language syntax?

Conclusion

Even in the case of language A where the "elvis operator" would make sense, its use is questionable because it is probably not general enough to justify the additon as a syntax/language feature.

Considering that adding special support for the "Elvis operator" would make the language quite a bit complex it probably makes more sense to pursue one or both of the other language apporaches, which add much more benefit over just an elaborate strategy to handle some unloved return values (which probably shouldn't be returned in the first place).

⇒ Treat null as a runtime error.

TL;DR

If you don't want to deal with nulls, the best strategy is stop using them. Don't return them, don't accept them as input parameters. This works in every language, regardless of always-nullable, nullable-by-default, non-nullable-by-default.

Things Which Should Be Fixed (IMHO)

A list of little, but annoying inconsistencies in Scala

Design Mistakes Inherited from Java

  • Special handling of Unicode escapes in single-line comments can inject arbitrary comments into source code. (#3220)
  • Implicit type widening from integer values to floating-point values. (#3235)

Unicode-aware Text-handling

Overview

While the well-known String class of Java's standard library has served developers well for the last decade as an easy-to-use wrapper around char[], there is currently no String class in widespread use which supports common operations like comparing two Strings for equality (as defined by the Unicode spec) or even counting the amount of glyphs (usually called 'characters') in a given String.

Some attempts have been made to fix this problem, like the addition of the java.text classes to Java or the ICU libraries, but neither have an easy-to-use API nor gained any actual usage.

Design considerations

  • Immutable
    • Thread-safe
    • Enables sharing
  • Ropes/Vector-like data structure
    • Fast operations like replace, insert, delete without having to copy the whole data
  • Fixed representation
    • Precise definition of UTF-8 + Normalisation + Decomposition format
    • Algorithms can make certain assumptions about the data
    • Enables fast operations on data
  • Default/configurable "branching factor" at construction?
  • Lazy normalization/decomposition?

Compiler Magic Should Be More Predictable/Overridable

Especially when compiler magic is used it is hard to know which programs will be accepted and which ones will be rejected by the compiler.

One example are the arbitrary rules about which compiler magic the user is allowed to override and which not. At the moment there is no general rule, but only decisions on a case-by-case basis, which is inconsistent and intuitive.

  • Overriding apply in case classes (like hashCode, equals) (#4126)
  • Multiple overloaded methods with default parameters (SO4652095)
  • Implicit in scope is not considered for fixing type mismatch in pattern matching (#4175)
  • Overriding class members (instead of having to rename and restructure the whole class)

Things Which Would Be Nice

Mutable Collections

  • Mutable versions of TreeMap and TreeSet (#4147)

Better Integration with Java Reflection

  • Objects inside objects don't show up with Java reflection (#4023)
    => Work on Scala reflection is currently underway.

Miscellaneous improvements to XML support

Scala Adoption - Top 5 Priorities

Documentation, Documentation, Documentation

Scaladoc

It is not acceptable that key classes are still not documented.
Additionally it is not possible to easily refer to external ressources, like JavaDoc. Pull request.

Website

The website does a bad job presenting Scala currently. Calling something "simple snippets [...] useful to understand some basics of the language" and then beating the reader with ClassManifests and implicits without any comment or documentation is an April fool's joke gone wrong.

Extend the reach of Scala

Scala LLVM (and Scala.NET) should get any help necessary. This is key feature to people who don't want or can't use the JVM. Start providing a supported solution.

Increase the depth of the platforms

Scala should come with more "real-world" platform-independent libraries. It is nice to have parser combinators as a part of the standard library, but what about:

  • IO
  • Networking
  • Date & Time

Communication

Currently it is more useful to scan Twitter for tweets with links mentioning #scala and to search on the internet for interviews by EPFL/Typesafe members on third-party sites than to look at the "official channels".

The website is next to useless in this regard, news are often not covered and when, then only with a substantial delay.

Coordination

Stop ignoring people offering help.

Organize people interested in working on some parts of the standard library, on the website, on ScalaDoc or on new libraries.

Be more helpful to new contributors and stop making up insane requirements about their work.