Alors bon, je ne suis pas sûr de trouver une analogie entre ces travaux et le système Entrelacs. Non pas que ces approches ne soient pas intéressantes, mais plutôt qu'elles sont "orthogonales" par rapport à la question de la représentation de l'information.
En fait, n'importe quel langage peut prendre place dans un système Entrelacs: concernant un langage fonctionnel, il peut être non typé, typé dynamiquement ou statiquement, typé simplement ou fortement. Un langage peut aussi offrir, comme le suggèrent les travaux que tu m'as recommandés, une algèbre des types permettant de démontrer par la preuve mathématique la sécurité du code. Bref, on peut faire ce qu'on peut déjà faire dans un système traditionnel.
Mais lire des articles sur les sujets que tu m'a conseillés m'a surtout permis d'identifier un peu mieux en quoi les aptitudes d'un langage peuvent être étendues par le choix d'une représentation des connaissances par des flèches.
Si l'on parle d'un langage comme Lisp par exemple. Et bien il s'agit d'un langage connu pour homogénéiser la syntaxe concrète et la syntaxe_abstraite d'une expression. Cela permet entre autres choses, de déclarer des macros qui modifient en profondeur l'interpréteur du langage. Cela peut permettre aussi de recréer de nouvelles fonctions qui viennent compléter ou remplacer des fonctions existantes.
Toutefois, même si les syntaxes abstraites et concrètes sont homogènes, elles restent fondamentalement séparées dans un système traditionnel, puisque que que la syntaxe abstraite correspond à la représentation en mémoire vive de l'arbre-expression du programme tandis que la syntaxe concrète est rattachée aux fichiers source du même programme dans le file system.
Or ces derniers échappent à la modification par le programme. C'est une opération trop complexe dans un système traditionnel. Un logiciel Lisp ne peut donc pas pratiquer l'intercession (Réflexion) au niveau de la syntaxe concrète. En d'autres termes, un agent Lisp peut modifier son propre programme une fois chargé en mémoire, mais il ne peut pas modifier le programme originel (le fichier source), ni les autres programmes du système. L'intercession n'est pas pérenne. La méta-programmation (des programmes qui manipulent des programmes) reste alors une technologie couteuse, et la réflexivité du langage Lisp une curiosité.
Entrelacs, en fusionnant tous les formats d'information structurées et tous les niveaux mémoires dans un espace unique pour tout le système, élimine cette contrainte arbitraire (même si elle peut être réintroduire plus tard pour des raisons de sécurité). C'est à dire qu'un langage à la Lisp dans Entrelacs peut facilement être enrichi d'opérateurs permettant à un programme, non seulement d'accéder à une représentation syntaxique de lui-même, mais aussi de modifier cette expression de façon pérenne.
Par ailleurs, on propose souvent en exercice de fabriquer rapidement un interpréteur Lisp en Lisp, histoire de démontre que Lisp est un peu la mère de tous les langages. Toutefois, l'état de l'interpréteur qui anime un programme est rarement lui-même accessible par le dit-programme.
Il est vrai que les langages fonctionnels permettent souvent de manipuler la continuation courante, de la mémoriser et de la restaurer. Mais Entrelacs permettrait sans peine à un programme de récupérer tout l'état de l'interpréteur à l'instant présent: la continuation, mais aussi l'environnement courant et l'expression courante, le tout sous la forme de flèches, c'est à dire des entités de premier ordre, manipulables par le programme. Le programme pourrait donc stocker tout ou une partie de cet état, le modifier, et enfin le réinjecter dans l'interpréteur. Par exemple, un agent pourrait faire une "sauvegarde immédiate" de lui-même exactement comme le font certains jeux vidéo.
Bon, je vais m'arrêter, c'est épuisant de parler dans le vide abyssal d'internet. Le but de ce forum était au départ d'arrêter de déblatérer tout seul dans mon coin. C'est un peu raté pour l'instant.
Quoi qu'il en soit, merci encore pour le coup d'oeil.
[^] # Re: euhhh
Posté par Sylvain Garden . En réponse au message projet "Entrelacs". Évalué à 2.
En fait, n'importe quel langage peut prendre place dans un système Entrelacs: concernant un langage fonctionnel, il peut être non typé, typé dynamiquement ou statiquement, typé simplement ou fortement. Un langage peut aussi offrir, comme le suggèrent les travaux que tu m'as recommandés, une algèbre des types permettant de démontrer par la preuve mathématique la sécurité du code. Bref, on peut faire ce qu'on peut déjà faire dans un système traditionnel.
Mais lire des articles sur les sujets que tu m'a conseillés m'a surtout permis d'identifier un peu mieux en quoi les aptitudes d'un langage peuvent être étendues par le choix d'une représentation des connaissances par des flèches.
Si l'on parle d'un langage comme Lisp par exemple. Et bien il s'agit d'un langage connu pour homogénéiser la syntaxe concrète et la syntaxe_abstraite d'une expression. Cela permet entre autres choses, de déclarer des macros qui modifient en profondeur l'interpréteur du langage. Cela peut permettre aussi de recréer de nouvelles fonctions qui viennent compléter ou remplacer des fonctions existantes.
Toutefois, même si les syntaxes abstraites et concrètes sont homogènes, elles restent fondamentalement séparées dans un système traditionnel, puisque que que la syntaxe abstraite correspond à la représentation en mémoire vive de l'arbre-expression du programme tandis que la syntaxe concrète est rattachée aux fichiers source du même programme dans le file system.
Or ces derniers échappent à la modification par le programme. C'est une opération trop complexe dans un système traditionnel. Un logiciel Lisp ne peut donc pas pratiquer l'intercession (Réflexion) au niveau de la syntaxe concrète. En d'autres termes, un agent Lisp peut modifier son propre programme une fois chargé en mémoire, mais il ne peut pas modifier le programme originel (le fichier source), ni les autres programmes du système. L'intercession n'est pas pérenne. La méta-programmation (des programmes qui manipulent des programmes) reste alors une technologie couteuse, et la réflexivité du langage Lisp une curiosité.
Entrelacs, en fusionnant tous les formats d'information structurées et tous les niveaux mémoires dans un espace unique pour tout le système, élimine cette contrainte arbitraire (même si elle peut être réintroduire plus tard pour des raisons de sécurité). C'est à dire qu'un langage à la Lisp dans Entrelacs peut facilement être enrichi d'opérateurs permettant à un programme, non seulement d'accéder à une représentation syntaxique de lui-même, mais aussi de modifier cette expression de façon pérenne.
Par ailleurs, on propose souvent en exercice de fabriquer rapidement un interpréteur Lisp en Lisp, histoire de démontre que Lisp est un peu la mère de tous les langages. Toutefois, l'état de l'interpréteur qui anime un programme est rarement lui-même accessible par le dit-programme.
Il est vrai que les langages fonctionnels permettent souvent de manipuler la continuation courante, de la mémoriser et de la restaurer. Mais Entrelacs permettrait sans peine à un programme de récupérer tout l'état de l'interpréteur à l'instant présent: la continuation, mais aussi l'environnement courant et l'expression courante, le tout sous la forme de flèches, c'est à dire des entités de premier ordre, manipulables par le programme. Le programme pourrait donc stocker tout ou une partie de cet état, le modifier, et enfin le réinjecter dans l'interpréteur. Par exemple, un agent pourrait faire une "sauvegarde immédiate" de lui-même exactement comme le font certains jeux vidéo.
Bon, je vais m'arrêter, c'est épuisant de parler dans le vide abyssal d'internet. Le but de ce forum était au départ d'arrêter de déblatérer tout seul dans mon coin. C'est un peu raté pour l'instant.
Quoi qu'il en soit, merci encore pour le coup d'oeil.