Re: l'INRIA ne soutient pas suffisamment OCaml

Posté par Yusei (page perso, ) le 01/05/2006 à 13:35. (lien). Évalué à 2.

mais ... c'est comme ça dans tous les langages.

(Pas en Lisp.)

Il y a une différence fondamentale entre ton exemple d'additions/multiplications et mon exemple de produit cartésien: tout le monde sait comment 5+3*6 est évalué. La priorité des opérateurs est là pour refléter l'écriture normale des opérations. Dans la vraie vie, un n-uplet s'écrit (a, b, c), rarement a, b, c, donc je ne vois pas pourquoi rendre les parenthèses facultatives. Si on le fait, on autorise à écrire [ 1 , 2 ; 1 , 3 ; 2 , 4 ; 3 , 1 ] au lieu de [ (1, 2) ; (1, 3) ; (2, 4) ; (3, 1) ]. Ce n'est pas ambigu, mais c'est difficile à lire. Si on n'a pas l'habitude du langage, certaines expressions non ambigues peuvent être trompeuses... en tout cas je me suis déjà fait avoir par cette règle.

Je prend un autre exemple tiré par les cheveux, en créant un opérateur qui additionne des couples:
# let (++) x y = fst x + fst y, snd x + snd y;;
# 1,1 ++ 1,2;;
This expression has type int but is here used with type int * int
# (1,1)++(1,2);;
- : int * int = (2, 3)

Là aussi, le code n'est pas ambigu. On aurait tort d'essayer 1,1 ++ 1,2 parce que l'opérateur s'appliquerait à deux entiers, pas à deux couples. Mais à mon avis c'est un piège inutile, et si le parenthèsage n'était pas facultatif on n'aurait jamais pu se tromper.

les autres atouts du langage en valent largement la peine.

Tout à fait, mais malgré tout je déplore les exceptions ou les variantes de sa syntaxe. La syntaxe du Lisp est plus abordable pour les débutants, parce qu'elle ne possède pas d'exceptions. Quand tu connais la règle (fonction arg1 ... argN) et les quelques formes spéciales, tu connais tout. En contrepartie, c'est un peu plus lourd à écrire.

Personnellement, je me satisfais assez d'un OCaml très parenthèsé, qui n'utilise qu'une seule manière de déclarer les fonctions, etc. Tant que je ne relis pas le codes des autres, bien sûr :)

[ Répondre ]