D'une manière générale, le principe du typage statique se situe dans la question : comment refuser d'exécuter un code qui plantera nécessairement ? ou plutôt, comment savoir qu'un bout de code plantera nécessairement avant de le lancer ?
Pour répondre au coup du Warning plutôt que de l'erreur pour le non respect du RANGE : Ada dispose d'une option pour forcer les Warning en Erreurs. Alors pourquoi laisser le choix ? Peut-être parce que le programmeur est un être libre :-) Non, blague à part, supposons que je souhaite écrire un test de couverture de code, car je m'interface avec un code en C qui ne dispose pas de ces vérifications de typage. Peut-être que cette option me facilitera l'écriture de mon cas de test.
Dans le cas de l'attribut qui n'existe pas selon le discriminant, il n'y aura même pas de Waring à la compilation. Uniquement une Erreur au Runtime. Ça me semble difficile de détecter tous les mauvais usages d'un type variant, surtout si on peut récupérer le record depuis un contexte extérieur (non-Ada). Il faut bien que ça plante quelque part, au niveau de l'interface, si on fait de la programmation par contrat, ou plus loin dans le code si on ne teste pas à l'entrée.
Après, on est d'accord, plus le compilateur englobe d'informations, plus il pourra nous aider à trouver les erreurs dans le code, voire dans sa sémantique. Mais si cette question était si simple, tout le monde coderait en COQ ! Comme ça tout serait toujours syntaxiquement et sémantiquement correct. Sauf que, si ce n'est pas le cas dans la pratique, c'est qu'il y a tout un tas de bonnes raisons de ne pas toujours le faire.
Haskell représente certainement un très bon compromis sur cette échelle, bien que lorsqu'on pousse le curseur un peu loin, le noyau de codeurs, aptes à comprendre de quoi il retourne, se réduit à peau de chagrin (cf. multiples discussions ci-dessus).
Ada, de son côté, a plein de limites, mais il a quand même été retenu pour bon nombre de projets dans des domaines tout à fait sérieux, et son système de typage (certes moins riche que celui de Haskell) n'y est sans doute pas étranger.
Beaucoup de choses entrent en ligne de compte lorsqu'on choisit un langage. Haskell et Ada sont sans doute de très bons candidats, chacun dans leur domaine d'excellence.
[^] # Re: Solution à base de types variants en ADA
Posté par gerfaut83 (site web personnel) . En réponse à la dépêche Sortie de GHC 8.0.2 et une petite histoire de typage statique. Évalué à 3.
Pour répondre au coup du Warning plutôt que de l'erreur pour le non respect du RANGE : Ada dispose d'une option pour forcer les Warning en Erreurs. Alors pourquoi laisser le choix ? Peut-être parce que le programmeur est un être libre :-) Non, blague à part, supposons que je souhaite écrire un test de couverture de code, car je m'interface avec un code en C qui ne dispose pas de ces vérifications de typage. Peut-être que cette option me facilitera l'écriture de mon cas de test.
Dans le cas de l'attribut qui n'existe pas selon le discriminant, il n'y aura même pas de Waring à la compilation. Uniquement une Erreur au Runtime. Ça me semble difficile de détecter tous les mauvais usages d'un type variant, surtout si on peut récupérer le
recorddepuis un contexte extérieur (non-Ada). Il faut bien que ça plante quelque part, au niveau de l'interface, si on fait de la programmation par contrat, ou plus loin dans le code si on ne teste pas à l'entrée.Après, on est d'accord, plus le compilateur englobe d'informations, plus il pourra nous aider à trouver les erreurs dans le code, voire dans sa sémantique. Mais si cette question était si simple, tout le monde coderait en COQ ! Comme ça tout serait toujours syntaxiquement et sémantiquement correct. Sauf que, si ce n'est pas le cas dans la pratique, c'est qu'il y a tout un tas de bonnes raisons de ne pas toujours le faire.
Haskell représente certainement un très bon compromis sur cette échelle, bien que lorsqu'on pousse le curseur un peu loin, le noyau de codeurs, aptes à comprendre de quoi il retourne, se réduit à peau de chagrin (cf. multiples discussions ci-dessus).
Ada, de son côté, a plein de limites, mais il a quand même été retenu pour bon nombre de projets dans des domaines tout à fait sérieux, et son système de typage (certes moins riche que celui de Haskell) n'y est sans doute pas étranger.
Beaucoup de choses entrent en ligne de compte lorsqu'on choisit un langage. Haskell et Ada sont sans doute de très bons candidats, chacun dans leur domaine d'excellence.