En fait, je pensais au cas d'usage qui reviennent au même.
Mais s'il y a trois notations distinctes ce n'est pas pour l'espace de fonctionnalité qu'elles ont en commun, mais justement pour les fonctionnalités où elles diffèrent.
il y a des situations où utiliser l'une ou l'autre ne change rien (c'est le cas de tous mes exemples, sauf le dernier qui était là pour montrer ce que seul les modules peuvent faire sans encodage tricky), mais il y a des cas d'usage que seul l'une des approche permet d'appréhender. Tout dépend des besoins du programmeur et des choix architecturaux qu'il fera pour son application. Si je veux juste un dictionnaire de valeurs, je prends un enregistrement ; si je veux un dictionnaire avec relation de sous-typage (la base du paradigme objet), je prends un objet ; si j'ai besoin d'un plus haut niveau d'abstraction et de généricité qu'offre le langage, je prends un module. Comme l'absence de généricité ne semble pas te gêner dans un langage (en 2017 pour un langage jeune, j'ai du mal à comprendre), je comprends que l'utilité des modules ne te semble pas évidente.
Je t'ai lu, plus d'une fois, disant que tu appréciais l'approche tagless-final pour l'interprétation1 mais sans un niveau de généricité acceptable tu oublies (et sans higher-kinded polymorphism ça doit être une plaie à faire): c'est une condition sine qua non que doit offrir le langage hôte pour la mettre en pratique !
même si c'est formel
Il ne faut pas trop se prendre la tête sur cette notion de formel ou de formalisme. Toute pensée, consciemment ou inconsciemment, explicitement ou implicitement, est formelle : une pensée informelle est un non-sens, une contradiction dans les termes, un carré rond si tu préfères. Ce que font les approches formelles c'est rendre explicite le formalisme sous-jacent qui se trouve à la source de la pensée exprimer dans tel ou tel langage.
Pour moi tout langage (et je ne parles pas là que des langages de programmation) n'est qu'une affaire d'interprétation, je préfère de loin cette notion à celle, souvent plus douteuse, de sémantique. Un compilateur : c'est une interprétation ; un type-checker : c'est une interprétation; un évaluateur : c'est une interprétation; un colorateur syntaxique : c'est une évaluation; une interface graphique : c'est une interprétation... La pensée, et de manière incidente son moyen d'expression : le langage, n'est rien d'autre qu'une affaire d'interprétation. ↩
Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
[^] # Re: go 2.0
Posté par kantien . En réponse au journal Pourquoi la recherche en langages de programmation ?. Évalué à 2.
Mais s'il y a trois notations distinctes ce n'est pas pour l'espace de fonctionnalité qu'elles ont en commun, mais justement pour les fonctionnalités où elles diffèrent.
Lorsque l'on écrit :
il y a des situations où utiliser l'une ou l'autre ne change rien (c'est le cas de tous mes exemples, sauf le dernier qui était là pour montrer ce que seul les modules peuvent faire sans encodage tricky), mais il y a des cas d'usage que seul l'une des approche permet d'appréhender. Tout dépend des besoins du programmeur et des choix architecturaux qu'il fera pour son application. Si je veux juste un dictionnaire de valeurs, je prends un enregistrement ; si je veux un dictionnaire avec relation de sous-typage (la base du paradigme objet), je prends un objet ; si j'ai besoin d'un plus haut niveau d'abstraction et de généricité qu'offre le langage, je prends un module. Comme l'absence de généricité ne semble pas te gêner dans un langage (en 2017 pour un langage jeune, j'ai du mal à comprendre), je comprends que l'utilité des modules ne te semble pas évidente.
Je t'ai lu, plus d'une fois, disant que tu appréciais l'approche tagless-final pour l'interprétation1 mais sans un niveau de généricité acceptable tu oublies (et sans higher-kinded polymorphism ça doit être une plaie à faire): c'est une condition sine qua non que doit offrir le langage hôte pour la mettre en pratique !
Il ne faut pas trop se prendre la tête sur cette notion de formel ou de formalisme. Toute pensée, consciemment ou inconsciemment, explicitement ou implicitement, est formelle : une pensée informelle est un non-sens, une contradiction dans les termes, un carré rond si tu préfères. Ce que font les approches formelles c'est rendre explicite le formalisme sous-jacent qui se trouve à la source de la pensée exprimer dans tel ou tel langage.
Pour moi tout langage (et je ne parles pas là que des langages de programmation) n'est qu'une affaire d'interprétation, je préfère de loin cette notion à celle, souvent plus douteuse, de sémantique. Un compilateur : c'est une interprétation ; un type-checker : c'est une interprétation; un évaluateur : c'est une interprétation; un colorateur syntaxique : c'est une évaluation; une interface graphique : c'est une interprétation... La pensée, et de manière incidente son moyen d'expression : le langage, n'est rien d'autre qu'une affaire d'interprétation. ↩
Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.