Re: Le cerveau n'est pas logique

Juste concernant Go, il me semble que l'approche (en tout cas des critiques que j'ai pu lire ici et là) n'est pas type-safe dans le sens où interface{} serait en réalité le type top comme la classe Object en Java - ce qui permet de facilement bypasser le système de type de Go.

C'est type-safe le interface{}, c'est un type existentiel. Par contre tu perds la garantie du typage statique et tu dois faire des assertions de type ou du switch sur type : il faut faire du typage dynamique. C'est comme en Python, en somme, sauf qu'en dehors de interface{} on a bien la garantie d'un typage statique (sans quantification universelle sur les types, c'est-à-dire, sans généricité mais c'est déjà pas trop mal). En gros, je le vois comme ça (je me trompe peut être) :

type intf = E : 'a -> intf
let i = E 1

mais comme Go garde des informations de typages au runtime, on peut retrouver à l'éxecution la valeur contenue dedans avec son type : pour Go, i est de type int et vaut 1.

var i interface{}
i = 1
fmt.Printf("i est de type %T et vaut %v", i, i)
// affiche : i est de type int et vaut 1

Ce qui n'est pas type-safe, c'est une valeur de tout type (avec quantification universelle sur les types). On parle de l'aspect unsound du système de type de Java (qui a des génériques) ou de la valeur undefined de Haskell ?

type contradiction = {faux : 'a. 'a}
let i = {faux = Obj.magic 1};;
val i : contradiction = {faux = <poly>}

Là, on contourne clairement le système de types, mais on annonce la couleur en utilisant le module Obj. ;-) Le type de faux, c'est le principe ex falso quodlibet.

Par contre j'ai un peu trop surestimé le système des interfaces : j'ai cru que c'était du type classes à la Haskell mais sans types paramétriques. En fait non, c'est clairement moins bien fait, tu ne peux pas avoir d'interface pour de telles méthodes :

type Vertex struct {
 X, Y float64
}
func (v *Vertex) Add(w *Vertex) Vertex {
 return Vertex{v.X + w.X, v.Y + w.Y}
}
func Add(v Vertex, w Vertex) Vertex {
 return v.Add(&w)
}
func main() {
 v := Vertex{3, 4}
 w := Vertex{5, 9}
 fmt.Println(Add(v,w))
} // affiche {8 13}

On ne peut pas définir le type interface de ceux qui implémentent la méthode Add : c'est nul et ça pourrait limiter le besoin de recourir à interface{}. Déjà qu'il n'ont pas de génériques (types paramétriques), ils auraient pu faire un effort de ce côté là.

En OCaml :

type 't add = { add : 't -> 't -> 't; }
type vertex = {x : float; y : float}
let add_vert = {add = fun v w -> {x = v.x +. w.x; y = v.y +. w.y}};;
val add_vert : vertex add = {add = <fun>}
let add_int = {add = (+)};;
val add_int : int add = {add = <fun>}
let add {add} x y = add x y;;
val add : 'a add -> 'a -> 'a -> 'a = <fun>
add (add_vert) {x =3. ; y = 4.} {x = 5. ; y = 9.};;
- : vertex = {x = 8.; y = 13.}
add (add_int) 3 4;;
- : int = 7

Le mécanisme des arguments implicites (s'il était implémenté) permettrait d'inférer automatiquement le 'a add à utiliser en fonction du type 'a des autres paramètres passés à add par unification, là où pour l'instant on doit le passer explicitement (c'est ce que font les types classes de Haskell mais en plus général, les types pouvant être paramétriques comme avec les monades). Go fait cela mais de manière très restreinte : la variable de type 't ne doit pas apparaître dans le type des champs de l'enregistrement. /o\

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