Les tags c'est ni plus ni moins que des types phantom, qui sont tout aussi disponible en OCaml. Cela commence à devenir amusant quand tu fais des opérations non triviales entre les tags, voir que tu transformes des valeurs connue seulement à l’exécution en type. Je crois que ce qui t'as posé problème en OCaml c'est le manque de surcharge d’opérateur (si je ne me trompe pas), mais si tu as de la surcharge, cela peut être très confortable à utiliser.
Merci, je vais jeter un œil, je ne connaissais pas, pourtant les trucs qui volent c'est un peu mon truc ;)
Tous les cas que tu cites ne sont pas des cas d'erreurs fréquents ou des difficultés particulières à détecter rapidement au runtime.
Pas fréquent, cela dépend. Pas difficile à détecter au runtime, c'est bien possible. C'est un compromis et je ne prétend pas avoir la réponse. En plus c'est un exercice difficile puisque il n'est pas aisé de quantifier l'impact dans un projet de ces méthodes. Si tu as un bug, tu peux juste imaginer ce que cela t'aurait coûté de ne pas l'avoir, mais si tu n'as pas de bug, c'est dur de savoir combien tu as économisé grâce à ta solution actuelle.
Si vous pouviez trouver un truc pour les API REST,
En haskell il y a https://www.servant.dev/, tu définis un type assez trapu et à partir de ce moment là tu as énormément de choses qui se font automatiquement, et tu ne peux pas compiler ton API REST tant qu'elle n'est pas implémentée correctement (pour une certaine définition de correctement). Qu'est ce que tu aimerais ?
ou encore, la gestion de la compatibilité ascendante lors d'un changement de version ("est-ce que le futur $ go get ./.. va tout péter ou pas ?").
Alors ça c'est un super problème, mais je pense que c'est indépendant du problème de typeage décrit dans ce journal.
[^] # Re: Nombre dans les types
Posté par Guillaum (site web personnel) . En réponse au journal Explorer des langages de programmation - édition 2020. Évalué à 2.
Les tags c'est ni plus ni moins que des types phantom, qui sont tout aussi disponible en OCaml. Cela commence à devenir amusant quand tu fais des opérations non triviales entre les tags, voir que tu transformes des valeurs connue seulement à l’exécution en type. Je crois que ce qui t'as posé problème en OCaml c'est le manque de surcharge d’opérateur (si je ne me trompe pas), mais si tu as de la surcharge, cela peut être très confortable à utiliser.
Merci, je vais jeter un œil, je ne connaissais pas, pourtant les trucs qui volent c'est un peu mon truc ;)
Pas fréquent, cela dépend. Pas difficile à détecter au runtime, c'est bien possible. C'est un compromis et je ne prétend pas avoir la réponse. En plus c'est un exercice difficile puisque il n'est pas aisé de quantifier l'impact dans un projet de ces méthodes. Si tu as un bug, tu peux juste imaginer ce que cela t'aurait coûté de ne pas l'avoir, mais si tu n'as pas de bug, c'est dur de savoir combien tu as économisé grâce à ta solution actuelle.
En haskell il y a https://www.servant.dev/, tu définis un type assez trapu et à partir de ce moment là tu as énormément de choses qui se font automatiquement, et tu ne peux pas compiler ton API REST tant qu'elle n'est pas implémentée correctement (pour une certaine définition de correctement). Qu'est ce que tu aimerais ?
Alors ça c'est un super problème, mais je pense que c'est indépendant du problème de typeage décrit dans ce journal.