La partie du message qui m'intéressait c'est "sum types are just types". Le traitement proposé des interfaces (comme des existentiels je suppose) est indépendant.
Une interface Go c'est:
- une valeur à un certain type \alpha
- un morceau d'information \mathsf{DynType}\;\alpha qui permet, quand on pattern-matche dessus, d'apprendre l'identité de \alpha (en fait c'est string, ou int, etc.)—il serait naturel de représenter cela comme un cas particulier de type algébrique (extensible) généralisé, GADT, mais on peut aussi définir des règles de typage spécifique comme Go fait pour les "type switches"
- de l'information (la vtable) sur où trouver les méthodes de l'interface, que l'on peut voir comme un produit/record des fonctions de l'interface et dont on peut appeler le type \mathsf{Dict}\;\alpha
- le tout empaqueté dans un type existentiel qui rend la valeur de \alpha "abstraite":
Il pourrait être intéressant de se demander si ça vaudrait le coup de donner accès à ces composants de façon indépendante :
Le fait que les existentiels sont forcément de la forme \exists alpha. (\alpha \times ...) veut dire que tu ne peux pas avoir une interface qui n'est pas attachée à précisément une valeur du type. Généraliser permettrait plus d'expressivité. En Haskell par exemple tu peux définir une classe de type Default a qui est disponible pour les types a qui ont une valeur par défaut, et on veut pouvoir invoquer la méthode default :: a sans avoir de valeur de ce type sous la main. Il y a aussi plein de cas où un existentiel trimballe plusieurs valeurs de type \alpha, une liste de valeurs, etc.
Dans certain cas tu veux que les gens n'aient pas accès au type dynamique de la valeur, pour pouvoir protéger ton abstraction (et donc avoir la garantir que tu peux changer le type concret sans casser le code de l'utilisateur de ta bibliothèque).
Ça semble être utile pour des choses comme un Marshall type-safe automatique d'une structure quelconque ou avec quelques restrictions (donc pas comme celui d'OCaml, qui n'est pas type-safe à la lecture) : je serais intéressé de savoir s'il y a des alternatives sans réflection, à la rigueur à coup de deriving semi-automatisé.
Les classes de type marchent assez bien pour gérer le type Dyntype a, parce que c'est typiquement le genre de valeurs que tu veux passer implicitement, et pour lequel tu n'as pas envie/besoin d'avoir plusieurs implémentations pour un même type. Sinon on peut ajouter cette construction en dur dans le langage, ça a été prototypé pour OCaml (Runtime types in OCaml), mais l'interaction avec les barrières d'abstraction (le système de module) est un problème délicat.
[^] # Re: go 2.0
Posté par gasche . En réponse au journal Pourquoi la recherche en langages de programmation ?. Évalué à 3.
La partie du message qui m'intéressait c'est "sum types are just types". Le traitement proposé des interfaces (comme des existentiels je suppose) est indépendant.
Une interface Go c'est:
- une valeur à un certain type \alpha
- un morceau d'information \mathsf{DynType}\;\alpha qui permet, quand on pattern-matche dessus, d'apprendre l'identité de \alpha (en fait c'est
string, ouint, etc.)—il serait naturel de représenter cela comme un cas particulier de type algébrique (extensible) généralisé, GADT, mais on peut aussi définir des règles de typage spécifique comme Go fait pour les "type switches"- de l'information (la vtable) sur où trouver les méthodes de l'interface, que l'on peut voir comme un produit/record des fonctions de l'interface et dont on peut appeler le type \mathsf{Dict}\;\alpha
- le tout empaqueté dans un type existentiel qui rend la valeur de \alpha "abstraite":
Il pourrait être intéressant de se demander si ça vaudrait le coup de donner accès à ces composants de façon indépendante :
Le fait que les existentiels sont forcément de la forme \exists alpha. (\alpha \times ...) veut dire que tu ne peux pas avoir une interface qui n'est pas attachée à précisément une valeur du type. Généraliser permettrait plus d'expressivité. En Haskell par exemple tu peux définir une classe de type
Default aqui est disponible pour les typesaqui ont une valeur par défaut, et on veut pouvoir invoquer la méthodedefault :: asans avoir de valeur de ce type sous la main. Il y a aussi plein de cas où un existentiel trimballe plusieurs valeurs de type \alpha, une liste de valeurs, etc.Dans certain cas tu veux que les gens n'aient pas accès au type dynamique de la valeur, pour pouvoir protéger ton abstraction (et donc avoir la garantir que tu peux changer le type concret sans casser le code de l'utilisateur de ta bibliothèque).
Les classes de type marchent assez bien pour gérer le type
Dyntype a, parce que c'est typiquement le genre de valeurs que tu veux passer implicitement, et pour lequel tu n'as pas envie/besoin d'avoir plusieurs implémentations pour un même type. Sinon on peut ajouter cette construction en dur dans le langage, ça a été prototypé pour OCaml (Runtime types in OCaml), mais l'interaction avec les barrières d'abstraction (le système de module) est un problème délicat.