Clojure Protocols vs Scala Structural Types

Question

After watching the interview with Rich Hickey on Protocols in Clojure 1.2, and knowing very little about Clojure, I have some questions on Clojure Protocols:

• Are they intended to do the same thing as Structural Types in Scala? What benefits do Protocols have over Structural Types (performance, flexibility, code clarity, etc.)? Are they implemented through reflections?
• Questions on interoperability with Scala: Can Protocols be used instead of Structural Types in Scala? Can they be extended (if 'extension' term can be applied to Protocols) in Scala?

Germander

About the first bullet, aren't type classes from Haskell closer to implicits in Scala? – Equilibrant

My understanding is that implicits and traits are Scala alternative to Type Classes (especially, when it comes to pimping of an existing functionality). But what can be achieved with Structural Types (and Protocols, I assume) is passing the instance of an existing type that you cannot (or don't want to) change to the API that just expects the passed object to have a special method to call: def call(c:{ def call():Unit }) = c.call() – Germander

Structural types are not related to type classes. – Sandiesandifer

I didn't say, they are related. Anyways, the mention of type-classes that attracts too much attention is removed from the question now :) – Germander

You should really watch this: vimeo.com/11236603. – Negotiation

Answer 1

Totally unrelated.

Scala is a statically typed language. Clojure is a dynamically typed language. This difference shapes both of them fundamentally.

Structural types are static types, period. They're just a way to have the compiler prove statically that an object will have a particular structure (I say prove here, but casting can cause bogus proofs as always).

Protocols in Clojure are a way to create dynamic dispatch that is much faster than reflection or looking things up in a map. In a semantic sense they don't really extend the capabilities of Clojure, but operationally they are significantly faster than the mechanisms used before.

Scala traits are a bit closer to protocols, as are Java interfaces, but again there's a static vs dynamic issue. Scala traits must be associated with a class at compile time, similar to Java interfaces. Clojure protocols can be added to a datatype at runtime after the fact even by a third party.

Something like Clojure protocols is possible in Java and Scala through mechanisms like wrapper/proxy patterns or dynamic proxies ( http://download.oracle.com/javase/1.4.2/docs/guide/reflection/proxy.html ). But those will be a heck of a lot clumsier than Clojure protocols and getting object identity right is tricky as well.

Innocuous

Although Clojure protocols can be extended at runtime, they are statically typed in the sense that the compiler will produce a statically typed function call based on the type of the first argument (or do a single interface cast if the type is not known / cannot be inferred). This is one of the reasons protocols are very fast compared to multimethods (the fully dynamic equivalent). – Genseric

Answer 2

The purpose of Protocols in Clojure is to solve the Expression Problem in an efficient manner.

[See: Simple explanation of clojure protocols.]

Scala's solution to the Expression Problem are Implicits. So, semantically, that is the closest equivalent to Clojure Protocols in Scala. (In Haskell, it would be Typeclasses or maybe Type Families.)

Shawn

Answer 3

As I understood from this introductory blogpost, Closure Protocols are closer to Scala Traits, rather than Structural Types (and thus, cannot be used as a replacement for them, answering my second question):

/* ----------------------- */
/* --- Protocol definition */
/* ----------------------- */

(defprotocol Fly
  "A simple protocol for flying"
  (fly [this] "Method to fly"))

/* --- In Scala */    
trait Fly{
    def fly: String
}

/* --------------------------- */
/* --- Protocol implementation */
/* --------------------------- */

(defrecord Bird [nom species]
  Fly
  (fly [this] (str (:nom this) " flies..."))

/* --- In Scala */    
case class Bird(nom: String, species: String) extends Fly{
    def fly = "%s flies..." format(nom)
}

/* --------------------- */
/* --- Dynamic extension */
/* --------------------- */

(defprotocol Walk
  "A simple protocol to make birds walk"
  (walk [this] "Birds want to walk too!"))

(extend-type Bird
  Walk
  (walk [this] (str (:nom this) " walks too..."))

/* --- In Scala */    
trait Walk{
    def walk = "Birds want to walk too!"
}

implicit def WalkingBird(bird: Bird) = new Walk{
    override def walk = "%s walks too..." format(bird.nom)
}

/* --------------- */
/* --- Reification */
/* --------------- */

(def pig (reify
                Fly (fly [_] "Swine flu...")
                Walk (walk [_] "Pig-man walking...")))

/* --- In Scala */    
object pig extends Fly with Walk{
    def fly = "Swine flu..."
    override def walk = "Pig-man walking..."
}

Germander

dynamic extension means using extend-protocol rather than defining a new protocol.... e.g. you could extend Fly to java.lang.String if you wanted..... – Genseric

You can use implicit conversions to achieve the same effect. That's what Scala does to extend Java's arrays. – Rudin

Answer 4

Other answers speak to the other parts of your question better, but:

Are they implemented through reflections?

No - protocols are compiled to JVM interfaces. Things which implement protocols (reify, defrecord, etc) are compiled to JVM classes which implement the protocol interface, so calls to protocol functions are the same as standard JVM method calls, under the hood.

That was actually one of the motivators for protocols - a lot of Clojure's internal data structures were written in Java, for speed reasons, because there was no way to do full-speed polymorphic dispatch in pure Clojure. Protocols provide that. Clojure still has a lot of Java in its source code, but that could all can now be rewritten in Clojure with no loss of performance.

Cuticula

So, although the answers above are emphasizing that the two things are different because one (in Clojure) is dynamic typing, but the other (in Scala) is static-typing (James Iry), but still they both correspond to underlying Java interfaces under the hood. So, indeed, they are similar, and even conceptually. – Horologium

BTW, the border between static and dynamic typing is not that strict. And Java was intentionally designed to look, from one side, as a statically typed language like C++, but from another side, to look like Smalltalk (dynamically typed). How is Java similar to dynamically-typed Smalltalk? Define sufficiently many interfaces (one for each method you employ) and you are almost there: whether you can call a method (= "send a specific message") to an object must not be related with whether it inherits some pieces of implementation from a suitable superclass. – Horologium

That programming style in Java (many interfaces to model the feel of Smalltalk)--although conceptually nice--required too much typing though. Scala language makes this style of programing for JVM elegant also on the surface by making these language's contructions short and readable! – Horologium

Cf. #1948569 . – Horologium

@HassanSyed depends on the code path. In many cases a protocol invocation can compile to a single invokevirtual JVM instruction, which is as fast as it can get. – Cuticula

Is that true that they don't add overhead compared to pure interface dispatch? Don't protocol calls always require an additional lookup into the MethodImplCache, so that they can extend existing types as well? – Provided