Comment les Futures sont-ils décrits en termes de théorie des catégories?

Existe-t-il une description utile des futurs ou des promesses en termes de théorie des catégories? En particulier, quel pourrait être le double catégorique du Futur?

En l'occurrence, j'écris un article à ce sujet maintenant. OMI, une bonne façon de penser aux futurs ou aux promesses est en termes de correspondance Curry-Howard pour la logique temporelle .

Fondamentalement, l'idée derrière les futurs est qu'il s'agit d'une structure de données représentant un calcul en cours et sur lequel vous pouvez synchroniser. En termes de logique temporelle, c'est l'opérateur éventuellement . Cela a une structure monadique: r e t u r n : A → ◊ A b i n d : ( A → ◊ B ) → ◊ A → ◊ B dans laquelle le r e t u r $\Diamond A$

$$\begin{array}{lcl} \mathrm{return} & : & A \to \Diamond A \\ \mathrm{bind} & : & (A \to \Diamond{B}) \to \Diamond{A} \to \Diamond{B} \end{array}$$ $\mathrm{return}$opération génère un processus qui retourne immédiatement son argument, et crée un nouveau processus qui attend un de valeur, applique f à cette valeur, puis attend le B -valeur avant de revenir. La proposition Promises / A pour CommonJS appelle l'opération de liaison monadique , et Scala 2.10 lui donne simplement l'interface monadique standard .$\mathrm{bind}$$a$$f$$B$then

Le double à l'opérateur éventuellement est l'opérateur toujours ◻ A la logique temporelle, qui dit que , à chaque instant, vous obtenez un A . Lorsque vous passez d'une sémantique de Kripke de logique temporelle (où vous modélisez simplement la prouvabilité) à une sémantique catégorielle d'un λ -calcul (où vous modélisez également des termes / preuves lambda), il s'avère qu'il existe en fait plusieurs façons de le faire.$\Diamond{A}$$\Box{A}$$A$$\lambda$

$\Box{A} \triangleq A$$A$

La chose la plus naturelle (OMI) à faire est de prendre , ce qui vous permet d'obtenir un (potentiellement différent) à chaque instant. Ensuite, vous pouvez voir le style comonadique de programmation réactive fonctionnelle (FRP) (proposé pour la première fois par Tarmo Uustalu et Varmo Vene ) comme le style de programmation dual à monadique avec les futurs.$\Box{A} \triangleq \mathsf{Stream}\;A$$A$

Cependant, le -calculus comonadique comme ils le suggèrent, malgré son élégance, provoque une sérieuse perte d'expressivité par rapport à la programmation explicite avec des flux, car la catégorie de charbon de bois libre qu'ils utilisent s'avère avoir trop peu d'éléments globaux pour dénoter de nombreux programmes intéressants , en particulier les points fixes.$\lambda$

Nick Benton et moi-même avons plaidé pour une programmation explicite avec des flux dans notre article Ultrametric Semantics of Reactive Programs . Par la suite, Alan Jeffrey a suggéré d'utiliser le LTL comme système de types dans son article LTL types FRP , une observation que Wolfgang Jeltsch a également faite dans son article Towards a Common Categorical Semantics for Linear-Time Tempic Logic and Functional Reactive Programming .

La différence entre la vue Nick et je prends, et celui que Alan et Wolfgang prendre est mieux comprise (OMI) en comparant la construction donnée dans Birkedal et al de. Premiers pas dans la théorie de domaine surveillé synthétique: étape-indexation dans les topos d'arbres avec le papier d'Alan. Les topos des arbres (préfiltres sur les nombres naturels classés par taille) sont très similaires à la catégorie des espaces ultramétriques que Nick et moi avons utilisés, mais beaucoup plus faciles à comparer avec la catégorie d'Alan (préfiltres sur une catégorie de temps discrète), car ce sont tous les deux des préfiltres catégories.

Si vous êtes intéressé par les contrats à terme spécifiquement pour la concurrence, alors ce serait peut-être une meilleure idée de regarder CTL plutôt que LTL, cependant. AFAIK, c'est un territoire actuellement inexploré!

EDIT: voici un lien vers le brouillon . Le document traite principalement de l'implémentation de FRP typé, donc le langage est synchrone. Mais la majeure partie de la discussion sur les futurs / événements dans la section 3.3 devrait également s'appliquer fondamentalement aux langages réellement concurrents.