Réponses:
Ohad a tout à fait raison quant aux problèmes rencontrés par le lambda calcul comme base de discussion des classes de complexité. Beaucoup de travail a été fait sur la caractérisation de la complexité de la réductibilité dans le lambda calcul, en particulier autour du travail sur les réductions étiquetées et optimales de la thèse de Lèvy. De manière générale, de bons modèles de coûts pour le lambda calcul ne devraient pas attribuer un poids constant à toutes les réductions bêta: intuitivement, substituer un grand sous-terme à de nombreux endroits de portée différente devrait coûter plus cher que de contracter un petit redex de K, et si l'on souhaite un certain montant d'invariance de coût sous différentes stratégies de réécriture, cela devient essentiel.
Deux liens:
Pour mieux répondre à votre question, un projet en cours développe et étudie un système de types (langage de programmation fonctionnel) qui, par analyse statique, peut déterminer les limites d'exécution (polynomiales) de programmes (ainsi que d'autres ressources utilisées par programmes). Donc, dans un certain sens, cela pourrait suggérer qu'il pourrait y avoir un avantage à utiliser la programmation fonctionnelle pour analyser la complexité de l'exécution. La page d'accueil du projet est ici .
Un article probablement représentatif de ce projet est: Jan Hoffmann, Martin Hofmann. Analyse de ressources amorties au potentiel polynomial - Inférence statique de bornes polynomiales pour les programmes fonctionnels. Dans Actes du 19e Symposium européen sur la programmation (ESOP'10). lien
Il existe une ligne de travail très intéressante basée sur la logique linéaire, appelée théorie de la complexité implicite, qui caractérise diverses classes de complexité en imposant diverses disciplines types au calcul lambda. IIRC, ce travail a commencé lorsque Bellantoni et Cook, et Leivant ont compris comment utiliser le système de types pour lier la récursion primitive afin de capturer diverses classes de complexité.
En général, l’intérêt de travailler avec les calculs lambda réside dans le fait qu’il est parfois possible de trouver des caractérisations plus extensives (c’est-à-dire plus exploitables mathématiquement) de diverses caractéristiques intensionnelles qui donnent aux modèles comme les machines de Turing leur puissance. Par exemple, une différence entre les machines Turing et le calcul lambda pur réside dans le fait que, puisque Turing reçoit des codes de programmes, un client peut implémenter manuellement des délais d'attente, pour implémenter la synchronisation en queue d'aronde - et peut donc calculer en parallèle ou. Cependant, les délais d'attente peuvent également être modélisés métriquement, et Escardo a supposé (je ne connais pas son statut) que les modèles d'espace métrique du lambda calcul sont totalement abstraits pour PCF + délais. Les espaces métriques sont des objets mathématiques très bien étudiés, et il est très agréable de pouvoir utiliser ce corpus théorique.
Cependant, la difficulté d'utiliser le lambda calcul est que cela vous oblige à affronter des phénomènes d'ordre supérieur dès le point de départ. Cela peut être très subtil, car la thèse de Church-Turing échoue pour un type supérieur - les modèles de calcul naturels diffèrent pour un type supérieur, car ils diffèrent par ce que vous êtes autorisé à faire avec les représentations de calculs. (Parallèle à-est un exemple simple de ce phénomène, car il présente une différence entre LC et TM.) De plus, il n'y a même pas d'inclusion stricte entre les différents modèles, car la contravariance de l'espace de fonction signifie que plus de pouvoir expressif à un ordre implique moins de pouvoir expressif un ordre plus élevé.
Autant que je sache, le lambda calcul est mal adapté à cette fin, car la notion de complexité spatio-temporelle est difficile à formuler dans le lambda calcul.
Qu'est-ce qu'une unité de complexité temporelle? Une réduction bêta? Qu'en est-il des unités de complexité de l'espace? La longueur de la ficelle?
Le calcul lambda convient mieux à la manipulation abstraite d'algorithmes, car il est beaucoup plus facile à composer que les machines de Turing.
Vous pouvez également rechercher des calculs de substitutions explicites qui décomposent la substitution au méta-niveau du lambda-calcul en une série d'étapes de réduction explicites. Cela rejoint l'idée de Charles selon laquelle toutes les substitutions ne doivent pas être considérées comme identiques lorsque l'on considère la complexité temporelle.
Voir Nils Anders Danielsson, Analyse de complexité temporelle semi-formelle légère pour des structures de données purement fonctionnelles implémentée sous forme de bibliothèque dans Agda. Les citations données dans le document semblent également très prometteuses.
Un élément clé à retenir pour moi est qu’il est approprié / utile / raisonnable / semi-automatisable de déduire la complexité temporelle des algorithmes dans le lambda calcul simplement typé, en particulier si ces algorithmes y sont facilement exprimables (c’est-à-dire purement fonctionnels), et surtout si Les algorithmes utilisent, par exemple, la sémantique appel par nom. À cela s’ajoute probablement le point évident que l’on ne calcule pas la complexité uniquement «dans le calcul lambda» mais dans le calcul lambda dans le cadre d’une stratégie d’évaluation donnée.