Typed Scheme (Un système de type pour Scheme)

Citation:

---

Envoyé par Jedai

[...]
Dans un langage comme OCaml ou Haskell, cette fonction ne peut être que l'identité (ou bottom pour Haskell), aucune autre fonction n'appartient à ce type, sauf si tu triches en fouillant les entrailles du langage (ou plutôt d'une de ses implémentations, distinction plus valide en Haskell qu'en OCaml bien sûr).

(Ou tu peux la voir comme l'application, mais c'est la même chose, à l'interprétation du nombre d'argument près)

--
Jedaï

---

C'est quoi que tu appelles identité ?

Code:

---

id : 'a -> 'a

---

??
Dans ce cas tu devrais relire la signature de ma fonction. Ce n'est pas ça.
C'est effectivement l'application !
C'est très différent de l'identité. La sémantique n'a rien à voir entre l'une et l'autre. Comment peux tu dire que c'est la même chose ?

Citation:

---

Envoyé par Jedai

On n'a pas dit que le nom était inutile, on a dit que dans plein de cas, la signature seule donne énormément d'information (parfois plus que le nom) sur la fonction. Tu as l'air de penser que la signature ne sert pratiquement à rien (excepté du point de vue mécanique de vérification de la correction), c'est ce point de vue que nous contestons.

--
Jedaï

---

Je n'ai JAMAIS dit ça !!! Lis ce que j'ai écris avant.

Citation:

---

Envoyé par Garulfo

Encore une fois, je n'ai pas dit que le typage est inutile: dans ma réponse je disais que si le programme est mal fait le typage ne t'aide pas ! Si le programme est bien fait, le typage aide c'est sûr.

---

J'ai dit que je comprenais très bien l'intérêt d'un système de typage !
Pourquoi voulez vous à tout prix que je sois contre un système de typage ?
Si c'est ce point de vue que tu contestes alors tu ne contestes personne !

Le débat à commencé lorsque j'ai dit que si je veux un langage typé, je choisis plutôt Haskell ou ocaml, et que l'intérêt de Scheme réside en son typage faible ! Mais j'ai bien précisé que ce n'était pas une attaque contre le système de typage. Loin de là. Tu n'as pas lu les autres messages c'est ça ?

Et je suis désolé, mais vous placez tous le typage comme plus important pour la compréhension d'un programme plutôt que son nom ! Et ça je suis convaincu que c'est faux. D'où l'idée de mon jeu.

Le nom est l'outil principal de la lecture d'un programme. Le typage est un outil supplémentaire mais est secondaire par rapport au nom. Le typage n'indique pas les préconditions d'une fonction, la documentation est aussi nécessaire. Donc je ne place pas le typage en outil numéro 1 de la compréhension d'un programme.

Citation:

---

Envoyé par SpiceGuid

Je vois mal comment ta fonction pourrait être autre chose que l'identité:

Code:

---

1 2	# let f (g:'a->'b) = g;; val f : ('a -> 'b) -> 'a -> 'b = <fun>

---

---

Et bien tu vois mal.
Ce qui démontre que le type n'est pas la chose la plus efficace.

Code:

---

1 2 3 4 5

# let id a = a ;; val id : 'a -> 'a = <fun> # let application f x = f x ;; val application : ('a -> 'b) -> 'a -> 'b = <fun>

---

Et on s'entend que c'était un exemple idiot car particulièrement simple.
Dans une autre de mes applications j'ai une signature qui donne

Code:

---

val f: float -> float array array

---

Comment pourriez vous devinez ce que fais f franchement ?
C'est pour cela qu'en fait ma signature donne

Code:

---

val f : angle:float -> matrice = <fun>

---

Je rajoute une étiquette pour que cela aide et je renomme le type float array array en matrice. Pourtant c'est loin d'être évident.
Si on rajoute le nom

Code:

---

creer_matrice_rotation_Ox

---

Ça indique ce que ça fait non ?
Le typage aide mais le nom est bien plus indicateur.

Je continue à penser que l'intérêt du type dans la compréhension d'une fonction est très inférieur au nom de la fonction. Et qu'on ne me dise pas que ce n'est pas ce que certains ont dit... c'est facile de retrouver les messages.

---

Donc je me requote moi même

Citation:

---

Encore une fois, je n'ai pas dit que le typage est inutile: dans ma réponse je disais que si le programme est mal fait le typage ne t'aide pas ! Si le programme est bien fait, le typage aide c'est sûr.

---

Et en paraphrasant en quelque sorte Jedaï, je vous dirais que vous vous obstinez à me dire le contraire, alors que je n'ai fait qu'énoncer une évidence. Si un programme est bien écrit, le nom d'une fonction est l'outil numéro 1 pour le comprendre. C'est le principe d'abstraction fonctionnelle qui limite la vue des détails pour nommer une tâche par un nom explicite. De plus, le type ajoute de l'information. Et la documentation donne les derniers détails.

Êtes vous toujours en désaccord avec ce que je dis là ?

Citation:

---

Envoyé par Garulfo

C'est effectivement l'application !
C'est très différent de l'identité. La sémantique n'a rien à voir entre l'une et l'autre. Comment peux tu dire que c'est la même chose ?

---

Jedai vient de te le dire, la sémantique est la même car les deux sont êta-équivalents.

Citation:

---

Envoyé par SpiceGuid

Jedai vient de te le dire, la sémantique est la même car les deux sont êta-équivalents.

---

Donc... quand tu as à utiliser l'application tu utilises l'identité ?
Vraiment ?

Je sais bien que cela fonctionne, mais vous pensez vraiment que c'est une bonne manière de faire ? D'un point de vue conceptuel c'est mauvais.
Désolé de te dire ça.

Mais bon supposons que j'admettes que tu pensais à apply lorsque tu m'as dit identité et que donc tu ne t'étais pas trompé. Est ce que sincérement, tu aurais deviné le comportement de la fonction de signature suivante

Code:

---

val f: float -> float array array

---

sans aucun nom ?

Hors quelle fonction as-tu le plus de chance de voir dans une vraie application ? id ou creer_matrice_rotation_Ox ??

Ou dois je comprendre à ton silence sur tout les autres points de mes réponses que tu es d'accord sur tout le reste et que donc le typage n'est pas plus important que les noms pour comprendre une fonction ?

Tout à fait, mon silence sur les autres points signifie que je ne cherche pas la contradiction, si les noms sont plus importants pour toi alors ainsi soit-il. D'ailleurs choisir des noms cours mais néanmoins descriptifs est une des clés de la lisibilité, c'est dit dans n'importe quel tutoriel (sauf le mien :oops:).

Citation:

---

Envoyé par Garulfo

C'est quoi que tu appelles identité ?

Code:

---

id : 'a -> 'a

---

??
Dans ce cas tu devrais relire la signature de ma fonction. Ce n'est pas ça.
C'est effectivement l'application !
C'est très différent de l'identité. La sémantique n'a rien à voir entre l'une et l'autre. Comment peux tu dire que c'est la même chose ?

---

Parce que c'est la même chose : l'application est juste l'identité restreinte au domaine des fonctions, (a -> b) -> a -> b peut s'écrire aussi bien (a -> b) -> (a -> b), et tu peux remplacer ton "application" par "id" sans que ça change rien à ton programme.

Citation:

---

Le typage aide mais le nom est bien plus indicateur.

Je continue à penser que l'intérêt du type dans la compréhension d'une fonction est très inférieur au nom de la fonction. Et qu'on ne me dise pas que ce n'est pas ce que certains ont dit... c'est facile de retrouver les messages.

---

Ok, alors reformulons mon opposition à ce que tu as dit : tu sous-estimes les signatures. Cela n'était il pas apparent lorsque par quatre fois tu nous as donné des signatures transparentes en nous mettant au défi de retrouver les fonctions correspondantes ?
Que certains aient été trop loin et affirmé que les noms aidaient moins à la compréhension que les signatures, peut-être, néanmoins je crois tout de même que les signatures sont une aide largement supérieure à ce que tu crois.

--
Jedaï

Citation:

---

Envoyé par Jedai

[...]tu sous-estimes les signatures.[...]

---

Ça peut être. Je suis convaincu que les noms sont plus importants. Mais je sous estime peut être l'utilisation des signatures. L'habitude de ne pas en utiliser probablement.

Maintenant je reprécise que je comprends très bien tout l'intérêt d'un système de type, au point que je ne manque pas de le mentionner à tous les nouveaux étudiants d'informatique. Mon point n'était donc certainement pas en ce sens.