25 research outputs found

    Idioms are oblivious, arrows are meticulous, monads are promiscuous

    Get PDF
    We revisit the connection between three notions of computation: Moggi’s monads, Hughes’s arrows and McBride and Paterson’s idioms (also called applicative functors). We show that idioms are equivalent to arrows that satisfy the type isomorphism A;B ' 1;(A ! B) and that monads are equivalent to arrows that satisfy the type isomorphism A;B ' A ! (1;B). Further, idioms embed into arrows and arrows embed into monads

    Idioms are oblivious, arrows are meticulous, monads are promiscuous

    Get PDF
    AbstractWe revisit the connection between three notions of computation: Moggiʼs monads, Hughesʼs arrows and McBride and Patersonʼs idioms (also called applicative functors). We show that idioms are equivalent to arrows that satisfy the type isomorphism A↝B≃1↝(A→B) and that monads are equivalent to arrows that satisfy the type isomorphism A↝B≃A→(1↝B). Further, idioms embed into arrows and arrows embed into monads

    Lewis meets Brouwer: constructive strict implication

    Full text link
    C. I. Lewis invented modern modal logic as a theory of "strict implication". Over the classical propositional calculus one can as well work with the unary box connective. Intuitionistically, however, the strict implication has greater expressive power than the box and allows to make distinctions invisible in the ordinary syntax. In particular, the logic determined by the most popular semantics of intuitionistic K becomes a proper extension of the minimal normal logic of the binary connective. Even an extension of this minimal logic with the "strength" axiom, classically near-trivial, preserves the distinction between the binary and the unary setting. In fact, this distinction and the strong constructive strict implication itself has been also discovered by the functional programming community in their study of "arrows" as contrasted with "idioms". Our particular focus is on arithmetical interpretations of the intuitionistic strict implication in terms of preservativity in extensions of Heyting's Arithmetic.Comment: Our invited contribution to the collection "L.E.J. Brouwer, 50 years later

    The arrow calculus

    Get PDF
    We introduce the arrow calculus, a metalanguage for manipulating Hughes's arrows with close relations both to Moggi's metalanguage for monads and to Paterson's arrow notation. Arrows arc classically defined by extending lambda calculus With three constructs satisfying nine (somewhat idiosyncratic) laws; in contrast, the arrow Calculus adds four constructs satisfying five laws (which fit two well-known patterns). The five laws were previous]), known to be sound; we show that they are also complete, and hence that the five laws may replace the nine

    Algebraic Effects and Effect Handlers for Idioms and Arrows

    Get PDF
    Plotkin and Power’s algebraic effects combined with Plotkin and Pretnar’s effect handlers provide a foundation for modular pro-gramming with effects. We present a generalisation of algebraic effects and effect handlers to support other kinds of effectful com-putations corresponding to McBride and Paterson’s idioms and Hughes ’ arrows

    Synthesizing Functional Reactive Programs

    Get PDF
    Functional Reactive Programming (FRP) is a paradigm that has simplified the construction of reactive programs. There are many libraries that implement incarnations of FRP, using abstractions such as Applicative, Monads, and Arrows. However, finding a good control flow, that correctly manages state and switches behaviors at the right times, still poses a major challenge to developers. An attractive alternative is specifying the behavior instead of programming it, as made possible by the recently developed logic: Temporal Stream Logic (TSL). However, it has not been explored so far how Control Flow Models (CFMs), as synthesized from TSL specifications, can be turned into executable code that is compatible with libraries building on FRP. We bridge this gap, by showing that CFMs are indeed a suitable formalism to be turned into Applicative, Monadic, and Arrowized FRP. We demonstrate the effectiveness of our translations on a real-world kitchen timer application, which we translate to a desktop application using the Arrowized FRP library Yampa, a web application using the Monadic threepenny-gui library, and to hardware using the Applicative hardware description language ClaSH.Comment: arXiv admin note: text overlap with arXiv:1712.0024

    Running Probabilistic Programs Backwards

    Full text link
    Many probabilistic programming languages allow programs to be run under constraints in order to carry out Bayesian inference. Running programs under constraints could enable other uses such as rare event simulation and probabilistic verification---except that all such probabilistic languages are necessarily limited because they are defined or implemented in terms of an impoverished theory of probability. Measure-theoretic probability provides a more general foundation, but its generality makes finding computational content difficult. We develop a measure-theoretic semantics for a first-order probabilistic language with recursion, which interprets programs as functions that compute preimages. Preimage functions are generally uncomputable, so we derive an abstract semantics. We implement the abstract semantics and use the implementation to carry out Bayesian inference, stochastic ray tracing (a rare event simulation), and probabilistic verification of floating-point error bounds.Comment: 26 pages, ESOP 2015 (to appear

    The F# Computation Expression Zoo

    Get PDF
    Program logic can often be structured using abstract computation types such as monoids, monad transformers or applicative functors. Functional programmers use those abstractions directly while main-stream languages often integrate concrete instances as language features – e.g. generators in Python or asynchronous computations in C# 5.0. The question is, is there a sweet spot between convenient, hardwired language features, and an inconvenient but flexible libraries? F# computation expressions answer this question in the affirmative. Unlike the “do” notation in Haskell, computation expressions are not tied to a single kind of abstraction. They support a wide range of abstractions, depending on what operations are available. F# also provides greater syntactic flexibility leading to a more intuitive syntax, without resorting to full macro-based meta-programming. We present computation expressions in a principled way, developing a type system that captures the semantics of the calculus. We demonstrate how computation expressions structure well-known abstractions including monoidal list comprehensions, monadic parsers, applicative formlets and asynchronous sequences based on monad transformers
    corecore