Je vois que tu as pensé à créer des types pour les litéraux. C'est une bonne idée.
J'ai un cas d'usage assez chiant quand tu veux créer des définitions de configuration pour un système. Imagines une liste de définition de message, tu peux avoir une matrice de base (exemple A429), une lib de ta boite (A429 + extension Thales), et tu veux tout mettre ensemble et ajouter les spécificités de ton équipements (pilote auto). La lib peut définir des messages (vitesse), messages définis dans le fichier final, mais qui peut contenir des informations comme "le type de la colonne 2 est un entier". Concrètement, cela veut dire que le type est une donnée comme une autre.
Aujourd'hui, vouloir faire cela avec les outils classiques imposent d'utiliser un enum et de recoder un système de typage.
Le deuxième point qui pourrait être très sympa, est d'étendre le concept de "constante propagation" lors de la phase d'optimisation en incluant les types structurées. Actuellement, ce genre d'optimisation ne marche qu'avec les types primitifs. Peu de langages permettent d'écrire un littéraux d'un type structuré ou une liste (comme le Json de JS). Imagines si on peut faire de la constante propagation de string, si on a un interpréteur de regexp, on obtient un compilateur de regexp. Les performances obtenus n'auraient plus rien à voir.
# type
Posté par Nicolas Boulay (site web personnel) . En réponse au journal [Letlang] Écrire un compilateur en Rust (partie 3). Évalué à 4.
Je vois que tu as pensé à créer des types pour les litéraux. C'est une bonne idée.
J'ai un cas d'usage assez chiant quand tu veux créer des définitions de configuration pour un système. Imagines une liste de définition de message, tu peux avoir une matrice de base (exemple A429), une lib de ta boite (A429 + extension Thales), et tu veux tout mettre ensemble et ajouter les spécificités de ton équipements (pilote auto). La lib peut définir des messages (vitesse), messages définis dans le fichier final, mais qui peut contenir des informations comme "le type de la colonne 2 est un entier". Concrètement, cela veut dire que le type est une donnée comme une autre.
Aujourd'hui, vouloir faire cela avec les outils classiques imposent d'utiliser un enum et de recoder un système de typage.
Le deuxième point qui pourrait être très sympa, est d'étendre le concept de "constante propagation" lors de la phase d'optimisation en incluant les types structurées. Actuellement, ce genre d'optimisation ne marche qu'avec les types primitifs. Peu de langages permettent d'écrire un littéraux d'un type structuré ou une liste (comme le Json de JS). Imagines si on peut faire de la constante propagation de string, si on a un interpréteur de regexp, on obtient un compilateur de regexp. Les performances obtenus n'auraient plus rien à voir.
"La première sécurité est la liberté"