En bref: comment les systèmes de types sont-ils classés dans des contextes académiques; en particulier, où puis-je trouver des sources fiables qui rendent les distinctions entre les différents types de système de types clairs?
Dans un sens, la difficulté avec cette question n'est pas que je ne trouve pas de réponse, mais plutôt que j'en trouve trop, et aucune ne se distingue comme correcte. Le fond est que j'essaie d'améliorer un article sur le wiki Haskell sur la dactylographie , qui réclame actuellement les distinctions suivantes:
- Pas de dactylographie: la langue n'a aucune notion de types, ou d'un point de vue typé: il y a exactement un type dans la langue. Le langage d'assemblage n'a que le type «motif binaire», Rexx et Tk n'ont que le type «texte», le noyau MatLab n'a que le type «matrice à valeurs complexes».
- Typage faible: il existe seulement quelques types distincts et peut-être des synonymes de types pour plusieurs types. Par exemple, C utilise des nombres entiers pour les booléens, les entiers, les caractères, les ensembles de bits et les énumérations.
- Typage fort: ensemble de types à grains fins comme dans Ada, langues wirthiennes (Pascal, Modula-2), Eiffel
Ceci est tout à fait contraire à ma perception personnelle, qui était plus dans le sens de:
- Typage faible: les objets ont des types, mais sont implicitement convertis en d'autres types lorsque le contexte l'exige. Par exemple, Perl, PHP et JavaScript sont tous des langages dans lesquels
"1"
peuvent être utilisés dans plus ou moins n'importe quel contexte qui le1
peut. - Typage fort: les objets ont des types et il n'y a pas de conversions implicites (bien que la surcharge puisse être utilisée pour les simuler), donc utiliser un objet dans le mauvais contexte est une erreur. En Python, l'indexation d'un tableau avec une chaîne ou un flottant lève une exception TypeError; à Haskell, il échouera au moment de la compilation.
J'ai demandé des avis à ce sujet à d'autres personnes plus expérimentées dans le domaine que moi, et l'une d'entre elles a donné cette caractérisation:
- Typage faible: l'exécution d'opérations invalides sur les données n'est ni contrôlée ni rejetée, mais produit simplement des résultats invalides / arbitraires.
- Typage fort: les opérations sur les données ne sont autorisées que si les données sont compatibles avec l'opération.
Si je comprends bien, la première et la dernière caractérisation appelleraient C faiblement typé, la seconde l'appellerait fortement typé. Le premier et le second appellent Perl et PHP faiblement typés, le troisième les appellent fortement typés. Tous les trois décriraient Python comme fortement typé.
Je pense que la plupart des gens me diraient "eh bien, il n'y a pas de consensus, il n'y a pas de sens accepté des termes". Si ces personnes se trompent, je serais heureux d'en entendre parler, mais si elles ont raison, comment les chercheurs CS décrivent-ils et comparent-ils les systèmes de types? Quelle terminologie puis-je utiliser qui est moins problématique?
Comme question connexe, je pense que la distinction dynamique / statique est souvent donnée en termes de "temps de compilation" et de "temps d'exécution", ce que je trouve insatisfaisant étant donné que la compilation ou non d'une langue n'est pas tellement une propriété de cette langue. que ses implémentations. Je pense qu'il devrait y avoir une description purement sémantique du typage dynamique versus statique; quelque chose comme «un langage statique est un langage dans lequel chaque sous-expression peut être saisie». J'apprécierais toute réflexion, en particulier les références, qui clarifierait cette notion.
la source
Réponses:
Historiquement, le terme «langage de programmation fortement typé» est apparu dans les années 70 en réaction aux langages de programmation largement utilisés, dont la plupart avaient des trous de type. Quelques exemples:
Dans Fortran, il y avait des choses appelées zones de stockage "COMMUNES", qui pouvaient être partagées entre les modules, mais il n'y avait aucune vérification pour voir si chaque module déclarait le contenu du stockage COMMUN avec les mêmes types. Ainsi, un module pourrait déclarer qu'un bloc de stockage COMMON particulier avait un entier et un autre un nombre à virgule flottante, et les données seraient corrompues en conséquence. Fortran avait également des déclarations "EQUIVALENCE", par lesquelles le même stockage pouvait être déclaré contenir deux objets différents de types différents.
Dans Algol 60, le type de paramètres de procédure a été déclaré comme étant simplement "procédure", sans spécifier les types de paramètres de la procédure. Ainsi, on pourrait supposer qu'un paramètre de procédure était une procédure acceptant des entiers, mais passer une procédure acceptant réellement comme argument. Cela entraînerait le même type de corruption que les déclarations COMMUNES et ÉQUIVALENCE. (Cependant, Algol 60 a éliminé les problèmes plus anciens.)
En Pascal, des "enregistrements de variantes" ont été ajoutés, qui étaient presque exactement comme les anciennes instructions EQUIVALENCE.
En C, des «transtypages de type» ont été ajoutés permettant à tout type de données d'être réinterprété en tant que données d'un type différent. Il s'agissait d'un trou de type plutôt délibéré destiné aux programmeurs qui supposément savent ce qu'ils font.
Les langages fortement typés conçus dans les années 70 étaient destinés à éliminer tous ces trous de type. Si vous explorez ce que cela signifie, cela signifie essentiellement que les représentations de données sont protégées. Il n'est pas possible de visualiser l'objet de données d'un type comme un objet d'un autre type qui se trouve avoir le même motif binaire que sa représentation interne. Les théoriciens ont commencé à utiliser le terme «indépendance de représentation» pour caractériser cette propriété au lieu de l'idée vague de «typage fort».
Notez que les langages typés dynamiquement comme Lisp qui effectuent une vérification complète du type au moment de l'exécution sont "fortement typés" dans le sens de protéger les représentations. Dans le même temps, les langages typés statiquement perdraient leur indépendance de représentation à moins de vérifier les limites du tableau. Ils ne sont donc pas "fortement typés" au sens strict du terme. En raison de ces conséquences anormales, le terme "fortement typé" est tombé en désuétude après les années 70. Lorsque le département américain de la Défense a élaboré des exigences rigoureuses pour la conception d'Ada, il a notamment exigé que la langue soit "fortement typée". (On pensait à l'époque que l'idée de "fortement typé" allait de soi. Aucune définition n'a été proposée. ) Toutes les propositions linguistiques soumises en réponse se sont dites "fortement dactylographiées". Lorsque Dijkstra a analysé toutes les propositions linguistiques, il a constaté qu'aucune d'entre elles n'était fortement typée et, en fait, la signification du terme n'était même pas claire. Voir le rapportEWD663 . Cependant, je vois que le terme est de nouveau utilisé maintenant, grâce à une jeune génération de chercheurs qui ne connaissent pas l'histoire mouvementée du terme.
Le terme "typé statiquement" signifie que toute vérification de type est effectuée statiquement et qu'aucune erreur de type ne se produit au moment de l'exécution. Si le langage est également fortement typé, cela signifie qu'il n'y a vraiment aucune erreur de type lors de l'exécution. Si, d'autre part, il existe des trous de type dans le système de type, l'absence d'erreurs de type au moment de l'exécution ne signifie rien. Les résultats pourraient être complètement corrompus.
Le nouveau débat sur le "typage fort vs faible" semble viser à savoir si certaines conversions de types doivent être autorisées. Autoriser une chaîne où un entier est requis est un "typage faible" selon ces gens. Il y a un certain sens à cela car tenter de convertir une chaîne en un entier peut échouer, si la chaîne ne représente pas un entier. Cependant, la conversion d'un entier en chaîne n'a pas ce problème. Serait-ce un exemple de "typage faible" selon ces gens? Je n'ai aucune idée. Je remarque que les discussions de Wikipédia sur le "typage faible" ne citent aucune publication à comité de lecture. Je ne pense pas que ce soit une idée cohérente.
Note ajoutée : Le point fondamental est que le terme "typage fort" n'est pas devenu un terme technique avec une définition rigoureuse. Cela ressemblait plus à ce que certains concepteurs de langage ressentaient: "notre système de type est solide; il capture toutes les erreurs de type; il n'a pas de trous de type" et, donc, lorsqu'ils ont publié leur conception de langage, ils ont affirmé qu'il était "fortement typé" . C'était un mot à la mode qui sonnait bien et les gens ont commencé à l'utiliser. Le document Cardelli-Wegner a été le premier que j'ai vu où une analyse a été fournie sur ce qu'il signifie. Mon message ici doit être considéré comme une élaboration de leur position.
la source
int
etlong
étant 32 bits, ou les deuxlong
etlong long
étant 64, un programme qui utilise un pointeur vers un de ces types pour écrire du stockage et utilise un pointeur de l'autre type pour le lire, ne déclenchera généralement pas une erreur d'exécution détectable, mais peut arbitrairement mal fonctionner de manière arbitraire. Le C moderne perd ainsi la sécurité de type présente dans d'autres langages, sans gagner la sémantique qu'avaient les implémentations de qualité du langage de Ritchie autrefois offert en échangeL'article que Uday Reddy a trouvé dans sa réponse, On Understanding Types, Data Abstraction, and Polymorphism (1985), donne les réponses suivantes:
la source
Des réponses faisant autorité peuvent être trouvées dans l'article d'enquête de Cardelli et Wegner: sur la compréhension des types, l'abstraction des données et le polymorphisme .
Rappelez-vous que, si le «typage fort» a une signification acceptée, le «typage faible» ne l'est pas. Tout échec de frappe forte peut être considéré comme faible et les gens peuvent différer sur le type d'échec acceptable et sur ce qui ne l'est pas.
la source