L'équivalence contextuelle d'une langue avec `quote`-`eval` est-elle triviale ou non?

13

Dans [1], Mitchell Wand a démontré que l'ajout de fexprs au calcul lambda pur banalise la théorie de l'équivalence contextuelle, ce qui signifie que deux termes sont contextuellement équivalents s'ils sont -congruents. En explorant le travail connexe, il est allé "notre résultat prolonge une vieille observation d'Albert Meyer [2] et rend l'équivalence contextuelle triviale". Mais en faisant référence à [2], ce qui a pu être trouvé n'est que la déclaration suivante de Meyer:αevalquote

J'ai d'abord pensé que dans les langages avec une fonction quote- evalcomme LISP [3], il n'y avait pas de distinction de type entre les objets syntaxiques et exécutables. En fait quote- evalsemble assez sûr dans LISP parce que, bien que quotesyntaxiquement ressemble à un opérateur de bonne foi, comme disons cond, il ne se comporte vraiment pas comme un (il n'a qu'un comportement au moment de l'analyse, pas au moment de l'exécution, par exemple, on ne peut pas passer quotecomme paramètre d'une procédure). Pourtant, je n'ai pas encore vu d'exemples convaincants où la fonctionnalité quote- evalvalait la peine.

Indépendamment d'une faille mineure dans ces commentaires qui peut induire le lecteur en erreur et déduire qui condpourrait être transmise comme paramètre à une procédure. Si je comprends bien, ce que Meyer a dit " quote- evalsemble assez sûr" signifie que quote- evalpeut ne pas banaliser la théorie équationnelle, bien qu'il n'ait pas fourni de preuve.

ÉDITER:

Comme l'a suggéré Martin, puisque les trois articles cités traitent des langues de la famille LISP, posons la question sous ce même cadre. L'équivalence contextuelle d'une langue avec quote- eval, en particulier LISP, sur terre est-elle triviale ou non?

[1] Mitchell Wand, The Theory of Fexprs Is Trivial . Lisp et Symbolic Computation 10 (3): 189-199 (1998).

[2] Albert Meyer, Puzzles in Programming Logic Workshop on Formal Software Development. 1984

[3] John McCarthy, fonctions récursives des expressions symboliques et leur calcul par la machine, la partie I . Communications de l'ACM en avril 1960.

journée
la source
1
Je suggérerais de considérer si vous pouviez rendre la question plus précise: il existe différentes façons de mettre en œuvre des constructions de type eval / quote et diverses options pour concevoir des équivalences contextuelles pour de tels calculs. Une publication récente intéressante est Reasoning About Multi-Stage Programs par Inoue, Taha.
Martin Berger
1
La distinction clé est entre CTMP (méta-programmation au moment de la compilation, comme illustré par Template Haskell, Lisp / Scheme / Racket and Converge ) et RTMP (méta-programmation au moment de l'exécution comme eval de Javascript ou MetaOCaml). Un autre paramètre est la saisie . Voici une présentation générale que j'ai donnée il y a quelques mois à ce sujet, assez superficielle, je le crains. En ce qui concerne les équivalences contextuelles, peu de travail a été fait, surtout en raison de l'état fluide du support de programmation pour la méta-programmation.
Martin Berger
1
@ plmday: BTW, le langage de programmation idéalisé que Wand formalise dans The Theory of Fexprs Is Trivial est assez différent de la méta-programmation Lisp. Le premier est RTMP, le second (selon les implémentations concrètes) ne l'est pas.
Martin Berger
1
@MartinBerger: Pouvez-vous publier votre discours en pdf?
Dave Clarke
1
@ Dave Clarke, bien sûr, le voici ! Commentaires bienvenus.
Martin Berger

Réponses:

2

Tout d'abord, cela dépend entièrement de ce que vous considérez comme votre ensemble de contextes. Si (quote [])est un contexte, alors l'équivalence contextuelle est l'équivalence syntaxique.

Traditionnellement, les contextes d'équivalence contextuelle sont considérés comme des contextes dans lesquels des "expressions", quelle que soit leur signification dans le langage, peuvent apparaître. Cela exclut les contextes comme "[]", où le contexte place son argument à l'intérieur d'un littéral de chaîne. Ce type de contextes a également été exclu par l'IIRC lorsqu'il a décrit à l'origine la transparence référentielle.

De ce point de vue, je pense que ce (quote [])n'est pas non plus un contexte. Au lieu de cela, les contextes sont les endroits où l'évaluation d'expression pourrait potentiellement se produire, comme dans le corps d'une fonction ou dans l'argument d'une application.

Potentiellement, cela signifie que dans un programme Lisp avec des macros (ou un programme Racket ou Scheme), vous ne savez pas quels sont les contextes jusqu'à ce que vous exécutiez le processus d'expansion de macros potentiellement non terminatif, car vous ne savez même pas où les expressions sont. Que vous pensiez que ce soit un problème ou non est principalement une question philosophique plutôt que technique.

Sam Tobin-Hochstadt
la source
Je pense qu'il y a une façon d'exclure (quote []), plutôt que des vœux pieux, un contexte: rejeter l'idée de traiter 'datumcomme du sucre syntaxique pour (quote datum), alors '[], comme ce "[]"n'est plus un contexte. Les macros de schéma ont de quotetoute façon été masquées .
jour
Je ne comprends pas ton commentaire, @day. Pourquoi la relation entre 'datumet (quote datum)change-t-elle quelque chose?
Sam Tobin-Hochstadt
Si quotec'est une construction de langage et 'datumdesugars (quote datum), les gens soutiendront plus probablement que (quote [])c'est un contexte. Si nous supprimons quotedu langage de base, mais que nous prenons en charge la 'datumsyntaxe littérale , ils le feront moins probablement parce que le similaire "[]"est bien connu pour ne pas être un contexte.
jour
@day, c'est un malentendu. Il n'y a pas une seule bonne définition du «contexte». C'est juste que différents contextes prennent en charge différentes notions d'équivalence contextuelle. Par exemple, les espaces sont significativement sémantiques dans le "[]"contexte, mais pas dans le (quote [])contexte. Ce que les "gens" pourraient soutenir n'est ni ici ni là-bas.
Sam Tobin-Hochstadt
Je suis d'accord qu'il n'y a pas une seule bonne définition du contexte. Mais il existe une définition traditionnelle basée sur la syntaxe abstraite, celle que Wand utilise dans son article et que Meyer utilise dans son article, pour questionner le statut d'équivalence contextuelle de Lisp. Vous avez suggéré de remplacer la définition traditionnelle du contexte par le contexte d'évaluation. Ce que j'ai suggéré est de conserver la définition traditionnelle du contexte, de la retirer quotede la syntaxe abstraite, mais de soutenir la syntaxe littérale (concrète) de la citation (insignifiante pour l'espace). D'après ce que je peux voir, les deux voies mènent à "Non" à la question d'origine.
jour