Oui, exactement. Tout l'intérêt de construire ton type manuellement est de justement bien délimiter ce qu'on a le droit de faire (mettre des Bla int et des Bli string dans un tableau) et de le dire au compilateur, qui pourra ainsi te prévenir si quelque chose ne va pas.
Quant au fait que ce soit plus lourd à utiliser, je ne suis pas d'accord, ça rajoute quelques lignes et ça fait gagner en clarté. Avec du typage dynamique, si tu te balades avec un tableau dans lequel tu n'as que des int, et que subitement tu lui mets une string à l'intérieur, ça n'est vraiment pas clair et il faudra souvent se fendre d'un commentaire. Avec du typage statique, tu préviens dès le départ, tu poses tes règles et tu t'y tiens.
Enfin, si tu mets plusieurs types différents dans un tableau, il va vraisemblablement falloir discriminer sur leur type quand tu voudras agir sur ces éléments. Avec les constructeurs de type, la solution est particulièrement élégante :
match a.(i) with
| Bla j -> print_int j
| Bli s -> print_string s
[^] # Re: pourquoi le lisp
Posté par Zakath . En réponse à la dépêche Sortie de SBCL 1.0. Évalué à 4.
Quant au fait que ce soit plus lourd à utiliser, je ne suis pas d'accord, ça rajoute quelques lignes et ça fait gagner en clarté. Avec du typage dynamique, si tu te balades avec un tableau dans lequel tu n'as que des int, et que subitement tu lui mets une string à l'intérieur, ça n'est vraiment pas clair et il faudra souvent se fendre d'un commentaire. Avec du typage statique, tu préviens dès le départ, tu poses tes règles et tu t'y tiens.
Enfin, si tu mets plusieurs types différents dans un tableau, il va vraisemblablement falloir discriminer sur leur type quand tu voudras agir sur ces éléments. Avec les constructeurs de type, la solution est particulièrement élégante :
match a.(i) with
| Bla j -> print_int j
| Bli s -> print_string s