Is Haskell’s type system formally equivalent to Java’s? [closed]

I realize some things are easier/harder in one language than the other, but I’m only interested in type-related features that are possible in one and impossible/irrelevant in the other. To make it more specific, let’s ignore Haskell type extensions since there’s so many out there that do all kinds of crazy/cool stuff.

(“Java”, as used here, is defined as standard Java SE 7; “Haskell”, as used here, is defined as standard Haskell 2010.)

Things that Java’s type system has but that Haskell’s doesn’t:

nominal subtype polymorphism
partial runtime type information

Things that Haskell’s type system has but that Java’s doesn’t:

bounded ad-hoc polymorphism
- gives rise to “constraint-based” subtype polymorphism
higher-kinded parametric polymorphism
principal typing

EDIT:

Examples of each of the points listed above:

Unique to Java (as compared to Haskell)

Nominal subtype polymorphism

/* declare explicit subtypes (limited multiple inheritance is allowed) */
abstract class MyList extends AbstractList<String> implements RandomAccess {

    /* specify a type's additional initialization requirements */
    public MyList(elem1: String) {
        super() /* explicit call to a supertype's implementation */
        this.add(elem1) /* might be overridden in a subtype of this type */
    }

}

/* use a type as one of its supertypes (implicit upcasting) */
List<String> l = new ArrayList<>() /* some inference is available for generics */

Partial runtime type information

/* find the outermost actual type of a value at runtime */
Class<?> c = l.getClass // will be 'java.util.ArrayList'

/* query the relationship between runtime and compile-time types */
Boolean b = l instanceOf MyList // will be 'false'

Unique to Haskell (as compared to Java)

Bounded ad-hoc polymorphism

-- declare a parametrized bound
class A t where
  -- provide a function via this bound
  tInt :: t Int
  -- require other bounds within the functions provided by this bound
  mtInt :: Monad m => m (t Int)
  mtInt = return tInt -- define bound-provided functions via other bound-provided functions

-- fullfill a bound
instance A Maybe where
  tInt = Just 5
  mtInt = return Nothing -- override defaults

-- require exactly the bounds you need (ideally)
tString :: (Functor t, A t) => t String
tString = fmap show tInt -- use bounds that are implied by a concrete type (e.g., "Show Int")

“Constraint-based” subtype polymorphism (based on bounded ad-hoc polymorphism)

-- declare that a bound implies other bounds (introduce a subbound)
class (A t, Applicative t) => B t where -- bounds don't have to provide functions

-- use multiple bounds (intersection types in the context, union types in the full type)
mtString :: (Monad m, B t) => m (t String)
mtString = return mtInt -- use a bound that is implied by another bound (implicit upcasting)

optString :: Maybe String
optString = join mtString -- full types are contravariant in their contexts

Higher-kinded parametric polymorphism

-- parametrize types over type variables that are themselves parametrized
data OneOrTwoTs t x = OneVariableT (t x) | TwoFixedTs (t Int) (t String)

-- bounds can be higher-kinded, too
class MonadStrip s where
  -- use arbitrarily nested higher-kinded type variables
  strip :: (Monad m, MonadTrans t) => s t m a -> t m a -> m a

Principal typing

This one is difficult to give a direct example of, but it means that every expression has exactly one maximally general type (called its principal type), which is considered the canonical type of that expression. In terms of “constraint-based” subtype polymorphism (see above), the principal type of an expression is the unique subtype of every possible type that that expression can be used as. The presence of principal typing in (unextended) Haskell is what allows complete type inference (that is, successful type inference for every expression, without any type annotations needed). Extensions that break principal typing (of which there are many) also break the completeness of type inference.

Java’s type system lacks higher kinded polymorphism; Haskell’s type system has it.

In other words: in Java, type constructors can abstract over types, but not over type constructors, whereas in Haskell, type constructors can abstract over type constructors as well as types.

In English: in Java a generic can’t take in another generic type and parameterize it,

public void <Foo> nonsense(Foo<Integer> i, Foo<String> j)

while in Haskell this is quite easy

higherKinded :: Functor f => f Int -> f String
higherKinded = fmap show

To complement the other answers, Haskell’s type system doesn’t have subtyping, while typed object oriented languages as Java do.

In programming language theory, subtyping (also subtype polymorphism or inclusion polymorphism) is a form of type polymorphism in which a subtype is a datatype that is related to another datatype (the supertype) by some notion of substitutability, meaning that program elements, typically subroutines or functions, written to operate on elements of the supertype can also operate on elements of the subtype. If S is a subtype of T, the subtyping relation is often written S <: T, to mean that any term of type S can be safely used in a context where a term of type T is expected. The precise semantics of subtyping crucially depends on the particulars of what “safely used in a context where” means in a given programming language. The type system of a programming language essentially defines its own subtyping relation, which may well be trivial.

Due to the subtyping relation, a term may belong to more than one type. Subtyping is therefore a form of type polymorphism. In object-oriented programming the term ‘polymorphism’ is commonly used to refer solely to this subtype polymorphism, while the techniques of parametric polymorphism would be considered generic programming…

One thing nobody’s mentioned so far is type inference: a Haskell compiler can usually infer the type of expressions but you have to tell the Java compiler your types in detail. Strictly, this is a feature of the compiler but the design of the language and type system determines whether type inference is feasible. In particular, type inference interacts badly with Java’s subtype polymorphism and ad hoc overloading. In contrast, the designers of Haskell try hard not to introduce features that impact type inference.

Another thing people don’t seem to have mentioned so far is algebraic data types. That is, the ability to construct types from sums (‘or’) and products (‘and’) of other types. Java classes do products (field a and field b, say) fine. But they don’t really do sums (field a OR field b, say). Scala has to encode this as multiple case classes, which isn’t quite the same. And while it works for Scala it’s a bit of a stretch to say Java has it.

Haskell can also construct function types using the function constructor, ->. While Java’s methods do have type signatures, you can’t combine them.

Java’s type system does enable a type of modularity that Haskell hasn’t got. It will be a while before there’s an OSGi for Haskell.

Filed under: softwareengineering - @ 01:48

Thẻ: haskell, java, static-typing, type-systems

Thiết kế website giá rẻ

Danh mục