Re: Raisons d'essayer Rust

Je me demande quels types d'applications tu as en tête, pour que le côté récursif en profondeur de la destructuration te semble à ce point indispensable.

Regarde par exemple ce fil de discussion ouvert par Gasche sur le forum OCaml : Musings on extended pattern-matching syntaxes. Tu verras à quel point le pattern matching est essentiel dans l'utilisation poussée des types sommes. Quand on a des types sommes un peu partout, on déstructure à tous les niveaux et tout le temps.

Je t'accorde que la différence est syntaxique, et ne concerne pas le système de types, mais elle est essentielle pour l'usage convenable de types sommes. Déjà qu'ils sont une plaie à définir en Go, qu'ils sont ouverts et non fermés, si en plus on n'a aucune construction syntaxique aidant à leur usage, ce qui est clair et net c'est que ce n'est absolument pas une alternative viable aux types sommes.

Quand je t'ai montré comment faire de la réflexion avec des GADT en OCaml, tu m'as répondu cela :

Ce n'est pas une petite différence ! Surtout que le « à la main » passe par le concept de GADT, qui n'est pas le plus accessible

Et après tu me présentes les interfaces comme alternatives crédibles aux types sommes, via ton encodage du dessus. Tu es à la limite de la mauvaise foi sur le coup.

Je veux bien t'accorder que le concept de GADT, si on veut en explorer tout le potentiel, est difficile d'accès. Mais le cas d'usage que je proposais est utilisable par n'importe qui, sans avoir besoin de saisir les subtilités qu'il y a derrière. Je redonne sa définition :

type _ ty = ..
type _ ty +=
 | Int : int ty
 | Float : float ty
 | List : 'a ty -> 'a list ty

Sans rien comprendre à ce qui passe derrière, lorsque l'on définit un nouveau type, disons celui-ci :

type moule = {pseudo : string; karma : int}

il suffit de faire avec :

type _ ty += Moule : moule ty

c'est-à-dire rajouter un constructeur constant qui à le nom du type puis lui donné le bon type. Ce n'est certainement pas plus compliqué que ton encodage de types somme ouverts. Et au fond, votre type interface {} ce n'est rien d'autre que celui-ci emballé dans un type existentiel :

type top = Top : 'a ty * 'a -> top

Exemple de code qui prend une interface {} et fait un switch sur type :

let f (Top (t, v)) = match t with
 | Int -> Format.printf "%d@." v
 | Float -> Format.printf "%f@." v
 | _ -> ()
(* et à l'usage *)
f (Top(Int, 1));;
1
- : unit = ()
f (Top(Float, 2.5));;
2.500000
- : unit = ()

Ce qui revient à ce que je disais depuis le début : vous avez un type somme extensible gérer par le compilateur pour chaque interface, qu'il enveloppe dans une type existentiel. Comme je l'ai fait : j'ai emballé le GADT extensible dans un couple (type, valeur) puis je fait du pattern matching sur des constantes : ce à quoi se résume ton encodage des types sommes en Go.

Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.