Hindley-Milner type systems to the rescue! (With a sprinkling of Haskell style type classes.)

  f :: Iterable a => a -> b
  f x = (do stuff with x...)

f is defined to be constrained to accept only on types which implement the Iterable interface (however that's defined) as it's first argument and the compiler (or interpreter) will enforce that constraint.

> Hindley-Milner type systems to the rescue!

You're implying that all type-systems derived from HM have a form of bounded polymorphism. They're not, for example OCaml does not have type classes (you could probably encode a lot into objects, though).

TYpe classes and the ML module system overlap in capabilities

http://www.cse.unsw.edu.au/~chak/papers/WC06.html

OCaml's nephew, F# does have bounded polymorphism though. Although it inherits that from the OOP side of its family.

False, ocaml has type classes now! (or maybe I'm thinking of coq)

I don't think so: If you want the equivalent of Haskell type classes in OCaml then you have to either use a functors or some sort of class IIRC. I'm sure Oleg will have done something though.

I believe they're experimental in Coq.

yup, you're right, you got to use functors or go home.

Yeup, some folks did show the functors + modules \equiv type classes in some sense, for system F or a variant thereof. Theres also an oleg approach too I think.

Haskell type classes are sufficiently flexible to represent things like 'does this type have a next method' without having to instrument the actual type.

But could that kind of type system be considered similar to the usual Java-like little-flexible static typing? I think I would prefer a static vs dynamic implemented as Java vs Python (since those are usually the subjects on every one of these discussions)

It's identical, conceptually. A type class can be thought of as a degenerate kind of Adapter pattern.

ALthough the name is confusing type classes are very much like interfaces in Java: you define a set of operations that you want and then instantiate concrete types to that interface.

The major differences between type classes and interfaces are: * In Java interfaces the interfaced type is restricted to the first argument (the this). In Haskell interfaces the interfaced type can also appear on return values and arguments. * In Java you need to decide what interfaces to implement when you create your class. Haskell allows interfaces to be implemented for previously existing types. * Java allows for subtyping. You can turn a monomorphic program into a polymorphic one just by creating subclasses while in Haskell you would need to rewrite your code to be explicitly polymorphic.

There's a difference between the implementation type and the protocol type. Or as Java calls them - Classes and Interfaces. Unfortunately most classical OO language collate the two, causing much confusion.

Haskell's typeclasses are very close to this, but even closer is Go. You just define and interface and the functions that require it, and the compiler goes off and check's by itself whether the type you're passing in satifies the interface - no need for you to annotate it yourself. You lose Haskell's nifty "deriving" feature, but it's even closer to Python's duck typing with compile time checks.

> the function doesn't care about the type, but just whether it implements a next() method?

You're describing an "existential" type.

... or a typeclass.

Scala's type system can handle this as it support type safe duck typing.