Je réalise que certaines choses sont plus faciles / plus difficiles dans une langue que dans l'autre, mais je ne m'intéresse qu'aux fonctionnalités liées au type qui sont possibles dans l'une et impossibles / non pertinentes dans l'autre. Pour le rendre plus spécifique, ignorons les extensions de type Haskell car il y en a tellement qui font toutes sortes de choses folles / cools.

("Java", tel qu'utilisé ici, est défini en tant que norme Java SE 7 ; "Haskell", tel qu'utilisé ici, est défini en tant que norme Haskell 2010. )

Ce que le système de types de Java a mais que Haskell n'a pas:

• polymorphisme nominal de sous-type
• informations de type d'exécution partielle

Choses que le système de types de Haskell a mais que celles de Java ne:

• polymorphisme ad-hoc lié
  • donne lieu à un polymorphisme de sous-type "basé sur des contraintes"
• polymorphisme paramétrique de type supérieur
• dactylographie principale

MODIFIER:

Exemples de chacun des points énumérés ci-dessus:

Unique à Java (par rapport à Haskell)

Polymorphisme nominal de sous-type

/* 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 */

Informations de type d'exécution partielle

/* 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 à Haskell (par rapport à Java)

Polymorphisme ad hoc limité

-- 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")

Polymorphisme de sous-type "basé sur des contraintes" (basé sur un polymorphisme ad-hoc lié)

-- 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

Polymorphisme paramétrique de type élevé

-- 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

Dactylographie principale

Il est difficile de donner un exemple direct avec celui-ci, mais cela signifie que chaque expression a exactement un type général maximum (appelé son type principal ), qui est considéré comme le type canonique de cette expression. En termes de polymorphisme de sous-type "basé sur la contrainte" (voir ci-dessus), le type principal d'une expression est le sous-type unique de chaque type possible dans lequel cette expression peut être utilisée. La présence d'un typage principal dans Haskell (non étendu) est ce qui permet une inférence de type complète (c'est-à-dire une inférence de type réussie pour chaque expression, sans aucune annotation de type nécessaire). Les extensions qui rompent le typage principal (il en existe beaucoup) cassent également la complétude de l'inférence de type.

Le système de types de Java manque de polymorphisme plus élevé. Le système de types de Haskell l'a.

En d'autres termes: en Java, les constructeurs de types peuvent abstraire sur les types, mais pas sur les constructeurs de types, alors qu'en Haskell, les constructeurs de types peuvent abstraire sur les constructeurs de types ainsi que sur les types.

En anglais: en Java, un générique ne peut pas prendre un autre type générique et le paramétrer,

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

alors que dans Haskell c'est assez facile

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

Pour compléter les autres réponses, le système de types de Haskell ne comporte pas de sous - typage , contrairement aux langages orientés objet typés, comme le fait Java.

En théorie du langage de programmation , le sous - type (également le polymorphisme de sous-type ou le polymorphisme d' inclusion ) est une forme de polymorphisme de type dans laquelle un sous - type est un type de données lié à un autre type de données (le supertype ) par une notion de substituabilité , ce qui signifie que les éléments de programme, généralement des sous-programmes ou des fonctions, écrites pour agir sur des éléments du supertype, peuvent également agir sur des éléments du sous-type. Si S est un sous-type de T, la relation de sous-typage est souvent écrite S <: T, pour signifier que tout terme de type S peut être utilisé en toute sécurité dans un contexte oùun terme de type T est attendu. La sémantique précise du sous-typage dépend de manière cruciale de ce que "est utilisé en toute sécurité dans un contexte où" signifie dans un langage de programmation donné. Le système de types d'un langage de programmation définit essentiellement sa propre relation de sous-typage, qui peut être triviale.

En raison de la relation de sous-typage, un terme peut appartenir à plus d'un type. Le sous-typage est donc une forme de polymorphisme de type. Dans la programmation orientée objet, le terme «polymorphisme» est couramment utilisé pour désigner uniquement ce polymorphisme de sous - type , alors que les techniques de polymorphisme paramétrique seraient considérées comme une programmation générique ...

L'inférence de type est une chose que personne n'a encore mentionnée: un compilateur Haskell peut généralement déduire le type d'expressions, mais vous devez indiquer vos types au compilateur Java en détail. Strictement, il s’agit d’une caractéristique du compilateur, mais la conception du langage et du système de types détermine si l’inférence de type est réalisable. En particulier, l'inférence de type interagit mal avec le polymorphisme de sous-type et la surcharge ad hoc de Java. En revanche, les concepteurs de Haskell s'efforcent de ne pas introduire de fonctionnalités ayant un impact sur l'inférence de type.

Une autre chose que les gens ne semblent pas avoir mentionnée jusqu’à présent concerne les types de données algébriques. C'est-à-dire la capacité de construire des types à partir de sommes ('ou') et de produits ('et') d'autres types. Les classes Java font des produits (champ a et champ b, disons) bien. Mais ils ne font pas vraiment de sommes (champ a OU ou champ b, disons). Scala doit l'encoder sous forme de plusieurs classes de cas, ce qui n'est pas tout à fait la même chose. Et bien que cela fonctionne pour Scala, il est un peu exagéré de dire que Java l’a.

Haskell peut également construire des types de fonction en utilisant le constructeur de fonction, ->. Bien que les méthodes de Java aient des signatures de type, vous ne pouvez pas les combiner.

Le système de types de Java permet un type de modularité que Haskell n'a pas. Il faudra un certain temps avant qu’il n’y ait un OSGi pour Haskell.