6 research outputs found

    Toward dependent choice: a classical sequent calculus with dependent types

    Get PDF
    International audienceThe dependent sum type of Martin-Löf's type theory provides a strong existential elimination, which allows to prove the full axiom of choice. The proof is simple and constructive: ACA:=λH.(λx.wit (H x),λx.prf (H x)):∀(x:A)∃(y:B)P(x,y)⇒∃(f:A→B)∀(x:A)P(x,f(x))AC_A := \lambda H. (\lambda x. wit\,(H\, x), \lambda x. prf\,(H\,x)) : \forall (x:A) \exists (y:B) P(x, y) \Rightarrow \exists (f:A\to B) \forall (x:A) P(x, f (x)) where 'wit' and 'prf' are the first and second projections of a strong existential quantifier. We present here a continuation of Herbelin's works, who proposed a way of scaling up Martin-Löf proof to classical logic. The first idea is to restrict the dependent sum type to a fragment of our system we call N-elimination-free, making it computationally compatible with classical logic. The second idea is to represent a countable universal quantification as an infinite conjunction. This allows to internalize into a formal system (called dPAω) the realizability approach as a direct proof-as-programs interpretation.In a recent paper, Ariola et al. presented a way to construct a CPS-translation for a call-by-need version of the λˉμμ~\bar\lambda\mu\tilde\mu-calculus, which allows some sharing facilities. Yet, this translation does notenjoy any typing property, and then does not give us a way of proving normalization. Moreover, the λˉμμ~\bar\lambda\mu\tilde\mu-calculus is typed with sequent calculus [4], which does not allow to manipulate dependent types immediately.We propose to deal with both problems while proving the normalization of our system in two steps. First, we translate our calculus to an adequate version of the λˉμμ~\bar\lambda\mu\tilde\mu-calculus that allows to manipulate dependent types on the N-elimination-free fragment. Then we will try to adapt the CPS-translation for call-by-need to our case, while adding it a type

    A Lightweight Hat::simple type-preserving instrumentation for self-tracing lazy functional programs

    Get PDF
    Existing methods for generating a detailed trace of a computation of a lazy functional program are complex. These complications limit the use of tracing in practice. However, such a detailed trace is desirable for understanding and debugging a lazy functional program. Here we present a lightweight method that instruments a program to generate such a trace, namely the augmented redex trail introduced by the Haskell tracer Hat. The new method is a major step towards an omniscient debugger for real-world Haskell programs

    Call-by-need is clairvoyant call-by-value

    Get PDF
    Call-by-need evaluation, also known as lazy evaluation, provides two key benefits: compositional programming and infinite data. The standard semantics for laziness is Launchbury’s natural semantics, which uses a heap to memoise the results of delayed evaluations. However, the stateful nature of this heap greatly complicates reasoning about the operational behaviour of lazy programs. In this article, we propose an alternative semantics for laziness, clairvoyant evaluation, that replaces the state effect with nondeterminism, and prove this semantics equivalent in a strong sense to the standard semantics. We show how this new semantics greatly simplifies operational reasoning, admitting much simpler proofs of a number of results from the literature, and how it leads to the first denotational cost semantics for lazy evaluation

    Lazy Call-By-Value Evaluation

    No full text
    Designing debugging tools for lazy functional programming languages is a complex task which is often solved by expensive tracing of lazy computations. We present a new approach in which the information collected as a trace is reduced considerably (kilobytes instead of megabytes). The idea is to collect a kind of step information for a call-by-value interpreter, which can then efficiently reconstruct the computation for debugging/viewing tools, like declarative debugging. We show the correctness of the approach, discuss a proof-of-concept implementation with a declarative debugger as back end and present some benchmarks comparing our new approach with the Haskell debugger Hat
    corecore