<p>Many languages have some form of expressing &quot;user-defined duck typing&quot;: defining a type by its <em>behavior</em>, rather than anything about the structure or data of an instance of the type itself. Haskell and Lean have typeclasses. Java, C#, Go, Julia, TypeScript, Idris, and many more have interfaces. Swift has protocols. Rust and Scala have traits. C++ and Nim have concepts. Standard ML, OCaml, and Agda have modules.</p>
<p>All of these allow for expressing <em>about</em> the same thing in their respective implementations. Which of these are exact synonyms? What are differing traits (heh) between these different concepts (heh)? Semantics vary by language, of course: but are there any broadly agreed-upon differences between a &quot;trait&quot; and a &quot;typeclass&quot;, for example? Modules (and classes, though classes are often complemented with interfaces instead of allowing multiple inheritance) are more broadly distinct from the others, but what <em>about</em> the others?</p>
<p>I am fairly aware of the specifics in implementation between different languages and am not looking for that as an answer, unless the broad answer to this question is &quot;there are no name-associated conventions&quot; in which case, so be it. (though if someone was particularly inclined to go through and write a comprehensive guide about the differences in individual languages' implementations, that'd certainly also be useful).</p>

<traits><classes><interfaces><typeclasses><modules>
Typeclasses, traits, interfaces, protocols: is there any consistent terminology?
CC BY-SA 4.0
2023-08-28T20:56:53.320Z
Interfaces in Java are not duck typing. A class which has the required methods with the required signatures is still not assignable to the interface type if the class doesn't declare that it implements that interface. The same is generally true in any object-oriented language with nominal (as opposed to structural) types. The generalised term for a type defined by its behaviour rather than its memory representation, is an [abstract data type](https://en.wikipedia.org/wiki/Abstract_data_type).
kaya3
CC BY-SA 4.0
2023-08-28T23:32:58.630Z
Do note that ADTs can be perfectly emulated in Java these days using interfaces
Seggan
<p><strong>No</strong>.</p>
<p>Computer science as a whole suffers from conflicting and incoherently defined terminology. There is no language-independent distinction between traits, and interfaces, and typeclasses, and protocols.</p>
<p>That being said: arguably there's no language-independent consistent definition of even a function (pure? total?)... and words are based on usage. In academia, these terms more often than not refer to the particular systems that implemented them: for example, <a href="https://dl.acm.org/doi/10.1145/75277.75283" rel="noreferrer">How to make ad-hoc polymorphism less ad-hoc</a> (typeclasses) and <a href="https://dl.acm.org/doi/10.1145/966873.806468" rel="noreferrer">An approach to multiple-inheritance subclassing</a> (traits). In the wild, &quot;typeclasses&quot; typically refer to Haskell typeclasses: &quot;interfaces&quot; typically refer to Java interfaces: &quot;traits&quot; typically refer to Rust traits: &quot;protocols&quot; presumably refer to one-of Swift or Elixir protocols: &quot;concepts&quot; presumably refer to one-of C++ or Nim concepts. Modules typically refer to an ML implementation.</p>
<p>(this answer has been rewritten from a previous self-answer addressing a less focused question)</p>

CC BY-SA 4.0
2023-08-28T21:20:15.750Z
2023-08-29T01:47:06.070Z
2023-08-29T01:47:06.070Z
apropos
CC BY-SA 4.0
2023-08-28T23:17:06.400Z
Your question could be helpful to someone looking for the difference between all these terms, but typeclasses, traits, interfaces, and protocols are not the same thing. Interfaces in Java are more like classes with multiple inheritance than anything else.
user
CC BY-SA 4.0
2023-08-28T23:24:39.230Z
Also, modules don't really do the same thing as interfaces. Of course, all the different concepts you've listed here are different ways of solving the same problems, but modules are kinda like typeclasses except with the instance not being implicitly provided.
user
CC BY-SA 4.0
2023-08-28T23:30:05.123Z
Interfaces in Java, sure. But other languages have interfaces too! I'm interested if there is a consistent distinction between interfaces, typeclasses, traits, protocols that isn't tied to particular language implementations. Or when implementing a similar feature do language designers simply reach into a bag and pull out a random name? Since there *is* this distinction between interfaces, concepts, and modules...
apropos
CC BY-SA 4.0
2023-08-28T23:49:18.203Z
Right, I'm saying that the phrase "approximately synonyms" makes it seem like they're all the same thing, which they're not. By the way, we're discussing this question in [chat](https://chat.stackexchange.com/rooms/146046/the-garbage-collector) if you want to join. Michael Homer suggested splitting this question up so it isn't comparing every one of those things at once
user
CC BY-SA 4.0
2023-08-28T23:55:23.843Z
Neat, I'll drop by.
apropos
CC BY-SA 4.0
2023-08-29T08:09:40.540Z
A function? Did you mean a procedure? A method? A subroutine?
Trang Oul
CC BY-SA 4.0
2023-08-29T15:29:16.290Z
I had a go at describing type classes in The Garbage Collector [here](https://chat.stackexchange.com/transcript/message/64290429#64290429). Note they are pretty different from interfaces. For instance, there is a way to extend the notion of one parameter type classes to n-parameter type classes but there is not really an equivalent of this for interfaces.
David Young
CC BY-SA 4.0
2023-08-29T19:27:43.940Z
I agree with you that `No` is the answer and that inter language terminology is problematic at best.  However, the situation is better than with maths.  With computer languages, at least each language is generally well specified, *and versioned* (!), and source code usually specifies what language & version it uses/expects. Whereas with math, we have a wild-west with no versioning and no specification of what math spec a particular proof or article adheres to.
Erik Eidt
# Typeclasses, traits, interfaces, protocols: is there any consistent terminology?
Posted by: username_0 on 2023-08-28
Many languages have some form of expressing "user-defined duck typing": defining a type by its *behavior*, rather than anything about the structure or data of an instance of the type itself. Haskell and Lean have typeclasses. Java, C#, Go, Julia, TypeScript, Idris, and many more have interfaces. Swift has protocols. Rust and Scala have traits. C++ and Nim have concepts. Standard ML, OCaml, and Agda have modules.

All of these allow for expressing *about* the same thing in their respective implementations. Which of these are exact synonyms? What are differing traits (heh) between these different concepts (heh)? Semantics vary by language, of course: but are there any broadly agreed-upon differences between a "trait" and a "typeclass", for example? Modules (and classes, though classes are often complemented with interfaces instead of allowing multiple inheritance) are more broadly distinct from the others, but what *about* the others?

I am fairly aware of the specifics in implementation between different languages and am not looking for that as an answer, unless the broad answer to this question is "there are no name-associated conventions" in which case, so be it. (though if someone was particularly inclined to go through and write a comprehensive guide about the differences in individual languages' implementations, that'd certainly also be useful).
**Tags:** traits classes interfaces typeclasses modules
> **Comments:**
> **username_1**: Interfaces in Java are not duck typing. A class which has the required methods with the required signatures is still not assignable to the interface type if the class doesn't declare that it implements that interface. The same is generally true in any object-oriented language with nominal (as opposed to structural) types. The generalised term for a type defined by its behaviour rather than its memory representation, is an [abstract data type](https://en.wikipedia.org/wiki/Abstract_data_type).  
> **username_2**: Do note that ADTs can be perfectly emulated in Java these days using interfaces  
---
## 1 answers
### Answer by username_0 on 2023-08-28. Score: 4 | Accepted answer
**No**.

Computer science as a whole suffers from conflicting and incoherently defined terminology. There is no language-independent distinction between traits, and interfaces, and typeclasses, and protocols.

That being said: arguably there's no language-independent consistent definition of even a function (pure? total?)... and words are based on usage. In academia, these terms more often than not refer to the particular systems that implemented them: for example, [How to make ad-hoc polymorphism less ad-hoc](https://dl.acm.org/doi/10.1145/75277.75283) (typeclasses) and [An approach to multiple-inheritance subclassing](https://dl.acm.org/doi/10.1145/966873.806468) (traits). In the wild, "typeclasses" typically refer to Haskell typeclasses: "interfaces" typically refer to Java interfaces: "traits" typically refer to Rust traits: "protocols" presumably refer to one-of Swift or Elixir protocols: "concepts" presumably refer to one-of C++ or Nim concepts. Modules typically refer to an ML implementation.

(this answer has been rewritten from a previous self-answer addressing a less focused question)
> **Comments:**
> **username_3** (2023-08-28): Your question could be helpful to someone looking for the difference between all these terms, but typeclasses, traits, interfaces, and protocols are not the same thing. Interfaces in Java are more like classes with multiple inheritance than anything else.  
> **username_3** (2023-08-28): Also, modules don't really do the same thing as interfaces. Of course, all the different concepts you've listed here are different ways of solving the same problems, but modules are kinda like typeclasses except with the instance not being implicitly provided.  
> **username_0** (2023-08-28): Interfaces in Java, sure. But other languages have interfaces too! I'm interested if there is a consistent distinction between interfaces, typeclasses, traits, protocols that isn't tied to particular language implementations. Or when implementing a similar feature do language designers simply reach into a bag and pull out a random name? Since there *is* this distinction between interfaces, concepts, and modules...  
> **username_3** (2023-08-28): Right, I'm saying that the phrase "approximately synonyms" makes it seem like they're all the same thing, which they're not. By the way, we're discussing this question in [chat](https://chat.stackexchange.com/rooms/146046/the-garbage-collector) if you want to join. Michael Homer suggested splitting this question up so it isn't comparing every one of those things at once  
> **username_0** (2023-08-28): Neat, I'll drop by.  
> **username_4** (2023-08-29): A function? Did you mean a procedure? A method? A subroutine?  
> **username_5** (2023-08-29): I had a go at describing type classes in The Garbage Collector [here](https://chat.stackexchange.com/transcript/message/64290429#64290429). Note they are pretty different from interfaces. For instance, there is a way to extend the notion of one parameter type classes to n-parameter type classes but there is not really an equivalent of this for interfaces.  
> **username_6** (2023-08-29): I agree with you that `No` is the answer and that inter language terminology is problematic at best.  However, the situation is better than with maths.  With computer languages, at least each language is generally well specified, *and versioned* (!), and source code usually specifies what language & version it uses/expects. Whereas with math, we have a wild-west with no versioning and no specification of what math spec a particular proof or article adheres to.  
---
