Scala – Scala as a Language for Generic Programming

comparisongenericsscala

In the paper “An Extended Comparative Study of Language Support for Generic Programming” by Garcia et al. an interesting comparison of programming languages features for generic programming is given:

enter image description here

with the brief explanation of terminology:

enter image description here

Can anyone test Scala support for generic programming inside this framework? I.e. add a column in the first table with explanations if possible.

Best Answer

As mentioned in one of the comments from the OP, this is the table that explains how Scala compares for generic programming support. Link to source pdf

table with Scala listed

Later on, the following summary is provided:

Scala
Using the CONCEPT pattern we can model multi-type concepts, multiple constraints and support retroactive modeling. Furthermore, Scala’s support for implicits means that the drawbacks of the Java and C# solutions in terms of the additional overhead, do not apply to Scala. Thus, Scala scores well in both the implicit argument deduction and the retroactive modeling criteria. Section 6 shows that associated types are supported in Scala through type members and dependent method types, and type members can also be used as type aliases.
As shown in Section 3, Scala supports lexically scoped models. Furthermore type-checking is fully modular. Prioritized overlapping implicits provide some support for concept-based overloading as illustrated by the zipWithN example in Section 6.5. However, overlapping models have to be structured using a subtyping hierarchy, which may not always be desirable. Thus, the score for this feature is only sufficient. Finally, Scala has full support for first-class functions and it also supports equality constraints.
In summary Scala turns out to be a language with excellent support for generic programming features, managing to fare at the same level, or even slightly better, than G (which was specially designed as a language for generic programming in the large) or Haskell (which has been recognized has having very good support for generic programming).

And then in the summary:

Type members and dependent method types add extra power to the language and a combination of the two mechanisms allows associated types to be expressed. In combination with implicits, type members and dependent method types make Scala an language ready for generic programming in the large

Related Solutions

Java Development – How New Java Development Influences Interoperability with Scala and Clojure

Actually Java 8 doesn't introduce much that will be detrimental to other JVM languages that interop with Java. The work done on Lambdas helped fix a number of small issues around invokedynamic, MethodHandles , MethodReferences etc - but apart from that it's carry on as normal. That said, there's a whole new bunch of APIs that the other JVM languages could potentially call into now. Which ones they'll use by default or not is up to them.

The largest change impacting interop actually came in with Java 7 - with the invokedynamic bytecode that allows dynamic/late binding calls within the JVM - something that was initially designed for the other languages on the JVM. It's since been very usefully adapted for Lamdbas, so as of Java 8, Java will actually start emitting these bytecodes.

Some languages (JRuby for example) are already heavily using invokedynamic, whilst others (Scala, Groovy et al) are still investigating its use or are in the early stages of patching it in. In theory it makes their dynamic calls almost as performant as existing Java invokestatic calls, as opposed to the myriad of slower workarounds they were forced to use in the past.

Java 9 will bring more challenges for JVM languages with project Jigsaw coming into the platform which will be the beginning of the end for traditionally class loading and classpaths for the JVM. The JVM language folks are pretty aware of this and I expect some sensible collaboration to take place.

Scala Infix Notation – How to Use It

Starting with version 2.10, Scala introduced implicit Classes to handle precisely this issue.

This will perform an implicit conversion on a given type to a wrapped class, which can contain your own methods and values.

In your specific case, you'd use something like this:

implicit class RichInt(x: Int) {
  def isAFactorOf(y: Int) = x % y == 0
}

2.isAFactorOf(10)
// or, without dot-syntax
2 isAFactorOf 10

Note that when compiled, this will end up boxing our raw value into a RichInt(2). You can get around this by declaring your RichInt as a subclass of AnyVal:

implicit class RichInt(val x: Int) extends AnyVal { ... }

This won't cause boxing, but it's more restrictive than a typical implicit class. It can only contain methods, not values or state.

Best Answer

Related Solutions

Java Development – How New Java Development Influences Interoperability with Scala and Clojure

Scala Infix Notation – How to Use It

Related Topic