Je ne connaissais pas le mot et dans a liste de programmes cités je ne connais que le Lisp (un peu).
Ce que je comprends est que dans un langage homoïconique (je mettrais bien un tréma sur le i) le programme est aussi un type de données.
Cela signifie que tu peux définir des fonctions d'ordre supérieur qui analysent, produisent, et modifient des procédures qui peuvent être exécutées.
Tu connais l'équation «Algorithms + Data Structures = Programs» qui sert de titre à un livre (Wirth). Pour écrire un programme il faut donc décider quelle information fait partie de l'algorithme et quelle information fait partie des données.
Cette décision peut avoir des conséquences très subtiles sur l'organisation d'un programme. Cette décision n'est pas figée: généraliser une procédure signifie souvent reexprimer une partie de l'information «algorithmes» en terme de «types de données».
Dans un langage homoïconique tu peux facilement:
— écrire une interpréteur du langage (la partie évaluation est gratuite);
— déléguer une procédure arbitraire à un autre processus;
— écrire des outils d'instrumentation (instrumenting, profiling) comme des fonctions du langage et pas des outils externes;
— écrire des outils de déboguage comme des fonctions du langage et pas des outils externes.
Pour le dernier, cela signifie que tu peux partiellement automatiser le déboguage du programme. Par exemple ton système en production peut t'envoyer un mail avec un rapport d'erreur très détaillé (partie du code ayant engendré une erreur non traitée et paramères), et ce sans l'aide d'un debogueur!
# Doué?
Posté par Michaël (site web personnel) . En réponse au message Homoiconicité. Évalué à 3.
Je ne connaissais pas le mot et dans a liste de programmes cités je ne connais que le Lisp (un peu).
Ce que je comprends est que dans un langage homoïconique (je mettrais bien un tréma sur le i) le programme est aussi un type de données.
Cela signifie que tu peux définir des fonctions d'ordre supérieur qui analysent, produisent, et modifient des procédures qui peuvent être exécutées.
Tu connais l'équation «Algorithms + Data Structures = Programs» qui sert de titre à un livre (Wirth). Pour écrire un programme il faut donc décider quelle information fait partie de l'algorithme et quelle information fait partie des données.
Cette décision peut avoir des conséquences très subtiles sur l'organisation d'un programme. Cette décision n'est pas figée: généraliser une procédure signifie souvent reexprimer une partie de l'information «algorithmes» en terme de «types de données».
Dans un langage homoïconique tu peux facilement:
— écrire une interpréteur du langage (la partie évaluation est gratuite);
— déléguer une procédure arbitraire à un autre processus;
— écrire des outils d'instrumentation (instrumenting, profiling) comme des fonctions du langage et pas des outils externes;
— écrire des outils de déboguage comme des fonctions du langage et pas des outils externes.
Pour le dernier, cela signifie que tu peux partiellement automatiser le déboguage du programme. Par exemple ton système en production peut t'envoyer un mail avec un rapport d'erreur très détaillé (partie du code ayant engendré une erreur non traitée et paramères), et ce sans l'aide d'un debogueur!