DOCSLIB.ORG

Variable Arity for LF

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

Variable Arity for LF Work in Progress John Tang Boyland Tian Zhao ETH Zürich, Switzerland University of Wisconsin-Milwaukee, USA University of Wisconsin-Milwaukee, USA [email protected] [email protected] ABSTRACT The metatheorem can be expressed in the LF-based proof The dependently-typed lambda calculus (LF) supports use system Twelf [6] as of meta-level binding in reasoning about bindings and hy- %theorem subst: potheticals in programming languages. That is, lambda ex- forall* {T} {F} {T'} {E} pressions in LF can be used to model binders and hypothet- forall {T1: {x} has-type x T ical judgments depending on fixed-size contexts. However, -> has-type (F x) T'} because LF does not have a concept of variable-arity func- {T2: has-type E T} tions, a hypothetical judgment depending on a variable-size exists {T3: has-type (F E) T'} context cannot be modeled as an LF function. This paper true. extends LF to support variable-arity functions. As a result, one can model hypothetical judgments with variable con- As the reader may have noticed, the LF meta-theorem is texts directly in the extended LF. The extended LF allows trivial, since the desired result can be obtained by meta-level one to represent statements more transparently than previ- application: t1 E t2. The same is true of the Twelf formula- ous work that uses complex meta-machinery to type the LF tion. This example shows the simplicity and power of LF- context. This is work in progress: we are still in the process based higher order abstract syntax and in particular of using of constructing a proof of correctness. LF functions for hypotheticals. In general, one may not be able to use the same family for both hypotheticals and judg- 1. INTRODUCTION ments, but instead has a separate type family (say \assm- type") for hypotheticals. Then the substitution lemma re- Using LF as the metatheory for a proof system allows one quires an inductive proof which is straight-forward.1 to model name binding and hypotheticals as LF functions. An important aspect is that the LF context is used for Γ. For example, the classic substitution lemma has the follow- In other words, the metatheorem itself operates in the scope ing form in Pierce's TAPL [8] of other bindings. Often a metatheorem is not true in all Lemma 1 (Substitution). If Γ; x:S ` t : T and Γ ` possible LF contexts (for example, one in which new \super- s : S, then Γ ` t[x 7! s]:T natural" numbers are posited) and thus the description of allowable LF contexts is part of the statement of a metathe- If we use the LF type families \exp" and \ty" for expressions orem. Twelf uses the concept of \regular worlds" [9] and and types respectively, and the LF type family \has-type" to Beluga [7] (another LF-based proof system) extends these represent both hypotheticals and also the typing judgment with more powerful context descriptors. But the basic idea itself, and if we use the LF context itself to represent Γ is shared between most (all?) LF-based proof systems. (explained in more detail later), we end up with the following When one cannot use the LF context to express a con- metatheorem (theorem about terms of LF): text of unknown size, the simple technique breaks down. Lemma 2. If we have LF terms of the following types: Consider the following lemma for F<: from the POPLmark challenge [2] T : ty, T0 : ty, E : exp, F : exp ! exp 0 t1 :Πx : exp: has-type x T ! has-type (F x) T Lemma 3 (Narrowing). If Γ; X<:Q; ∆ ` M <: N and t2 : has-type ET Γ ` P <: Q, then Γ; X<:P; ∆ ` M <: N. then we can construct an LF term of type: has-type (FE) T0 Here, one cannot express the lemma in LF since ∆ may . depend on X. If ∆ is placed in the LF context, then any bindings in it that depend on X would be out of scope, a meta-level type error. Twelf's POPLmark solution splits the assumption X<:Q into two parts: the binding of the X which goes into the LF context whereas the subtyping assumption remains an explicit parameter. Basically, one could say that Γ; X<:Q; ∆ is represented by Γ; X; ∆; assume X<:Q and then DRAFT (June 21, 2014) of paper to be pre- 1Unless the type system (and Γ) permits dependent types, sented July 17 at LFMTP 2014, Vienna, Aus- in which case, one must use more complex techniques, or tria. indeed use the extension in this paper. 1 all but the last assumption are pushed into the LF context. a 2 A constant type family Beluga and SASyLF [1] (an LF-based proof system geared c 2 C constant term to teaching) prove narrowing for the empty ∆ case using x 2 X variable meta-level application (as with Substitution above), thus b 2 B tuple type constructor avoiding the need to express or prove the narrowing lemma g ::= x:T j @x:@T bindings in full generality. [@] K ::= [@] type j Πg. [@] K kinds This paper proposes @LF, LF extended with variable- arity functions. Then the narrowing lemma can be repre- T ::= a j T [@] e j Πg.T types sented as follows (for simplicity, we continue to use the LF @T ::= b e variable type context for Γ): e ::= x j c j e [@] e j λg.e terms Lemma 4. If we have @LF terms of type Γ ::= · j Γ; g contexts S ::= · j S; s signatures P : ty, Q : ty, D : ty ! desc, M :ΠX : ty:(ctx(DX)) !@ ty, U ::= () j Σg.U j λg.U tuple type @ N :ΠX : ty:(ctx(DX)) ! ty, s ::= signature element: t1 :ΠX : ty: assm-sub XQ ! Π@G : ctx (DX): a :: K type family sub-type (M X @G)(N X @G) j c : T constructor t2 : sub-type PQ j b :: Πx : a. @type tuple type family (here D represents ∆ with its dependency on the type vari- j b+c = U tuple constructor equation able being narrowed) then we can construct an @LF term of type Figure 1: Syntax of @LF, extensions highlighted. ΠX : ty: assm-sub XP ! Π@G : ctx (DX): sub-type (M X @G)(N X @G) The extension includes variable-arity functions for which the head of \newt empty X"). We apply the expansion to the formal and actual parameters are marked with \@." For ex- arguments and then after noting that \ctx+empty" expands ample, the M term represents a type term but can depend on to the empty tuple type, we end up with the following tuple X (a normal parameter) and on ∆ (represented with variable type: parameter G of type \ctx (DX)"). Here D returns a context ΣY : ty: Σb : (assm-sub YX): () \descriptor": a normal LF type family whose values describe the shape of elements of an @LF \tuple type" family, here When the explicit tuple here is substituted for the variable \ctx." The \@" over the arrow on the type of M reminds us arity parameter, it is flattened out, Σ becomes Π, and we that this is a variable-arity function type. end up with the following as the type of M (and N): The (LF) type family \desc" and the @LF type family ΠX : ty: ΠY : ty: Πb : (assm-sub YX): ty \ctx" can be defined (the latter using equations to dependent tuple types U, written () or Σg:U): If ∆ is larger still, we will use a larger descriptor D. In the proof of Lemma 4, one would use induction on t1 and thus empty : desc the fact that D gets bigger is not an issue. @ newt : ΠD : desc: (ctx D ! ty) ! desc Thus the main contribution of @LF is that it permits a context of unknown size to be typed using a descriptor in ctx+empty = () such a way that we can form types of judgments that depend @ ctx+newt = λD : desc: λT : (ctx D ! ty): on these contexts. Σ@G : ctx D:ΣX : ty: Σa : assm-sub X (T @G): () In general, since the descriptor is a normal LF type, using @LF, one can reason about contexts much more generally. The equations are used to replace known instances of @LF One can define well-formedness conditions on contexts in types families with dependent tuple types which are ex- the same way as for any other type. This ability would be panded in place. The syntax here is chosen for simplicity; welcome, since (with more than seven years experience using in practice, a pattern-matching style would be preferable. Twelf), the first author finds it frustrating that one cannot To help understand how this works, consider the following express and use the fact that (say) all natural numbers used examples. First suppose that D = λX : ty:empty; in other in a particular context are unique. words, the context ∆ in the Lemma 3 is empty. In that The remainder of this paper gives a precise definition of case, because of the equation for ctx+empty, the type \ctx the extension, and then discusses current directions. (DX)" is the empty tuple type which flattens to mean no parameters. In that case M and N have type ty ! ty; they depend on X and the (implicit) LF context representing Γ 2. DEFINITIONS but nothing else. Similarly t1 will have the type: Figure 1 gives the syntax of @LF including LF; the changes are highlighted. There are two kinds of bindings: normal ΠX : ty: assm-sub XQ ! sub-type (MX)(NX) bindings and variable bindings; the latter are typed by \b e," Next suppose instead that D ends up being\λX.newt empty a tuple type constructor b applied to an expression e, nor- X", means that ∆ consists of a single (new) type variable Y mally a variable.
Recommended publications
  • No-Longer-Foreign: Teaching an ML Compiler to Speak C “Natively”

    No-Longer-Foreign: Teaching an ML Compiler to Speak C “Natively”

    Electronic Notes in Theoretical Computer Science 59 No. 1 (2001) URL: http://www.elsevier.nl/locate/entcs/volume59.html 16 pages No-Longer-Foreign: Teaching an ML compiler to speak C “natively” Matthias Blume 1 Lucent Technologies, Bell Laboratories Abstract We present a new foreign-function interface for SML/NJ. It is based on the idea of data- level interoperability—the ability of ML programs to inspect as well as manipulate C data structures directly. The core component of this work is an encoding of the almost 2 complete C type sys- tem in ML types. The encoding makes extensive use of a “folklore” typing trick, taking advantage of ML’s polymorphism, its type constructors, its abstraction mechanisms, and even functors. A small low-level component which deals with C struct and union declarations as well as program linkage is hidden from the programmer’s eye by a simple program-generator tool that translates C declarations to corresponding ML glue code. 1 An example Suppose you are an ML programmer who wants to link a program with some C rou- tines. The following example (designed to demonstrate data-level interoperability rather than motivate the need for FFIs in the first place) there are two C functions: input reads a list of records from a file and findmin returns the record with the smallest i in a given list. The C library comes with a header file ixdb.h that describes this interface: typedef struct record *list; struct record { int i; double x; list next; }; extern list input (char *); extern list findmin (list); Our ml-nlffigen tool translates ixdb.h into an ML interface that corre- sponds nearly perfectly to the original C interface.
  • A Call-By-Need Lambda Calculus

    A Call-By-Need Lambda Calculus

    A CallByNeed Lamb da Calculus Zena M Ariola Matthias Fel leisen Computer Information Science Department Department of Computer Science University of Oregon Rice University Eugene Oregon Houston Texas John Maraist and Martin Odersky Philip Wad ler Institut fur Programmstrukturen Department of Computing Science Universitat Karlsruhe UniversityofGlasgow Karlsruhe Germany Glasgow Scotland Abstract arguments value when it is rst evaluated More pre cisely lazy languages only reduce an argument if the The mismatchbetween the op erational semantics of the value of the corresp onding formal parameter is needed lamb da calculus and the actual b ehavior of implemen for the evaluation of the pro cedure b o dy Moreover af tations is a ma jor obstacle for compiler writers They ter reducing the argument the evaluator will remember cannot explain the b ehavior of their evaluator in terms the resulting value for future references to that formal of source level syntax and they cannot easily com parameter This technique of evaluating pro cedure pa pare distinct implementations of dierent lazy strate rameters is called cal lbyneed or lazy evaluation gies In this pap er we derive an equational characteri A simple observation justies callbyneed the re zation of callbyneed and prove it correct with resp ect sult of reducing an expression if any is indistinguish to the original lamb da calculus The theory is a strictly able from the expression itself in all p ossible contexts smaller theory than the lamb da calculus Immediate Some implementations attempt
  • What I Wish I Knew When Learning Haskell

    What I Wish I Knew When Learning Haskell

    What I Wish I Knew When Learning Haskell Stephen Diehl 2 Version This is the fifth major draft of this document since 2009. All versions of this text are freely available onmywebsite: 1. HTML Version ­ http://dev.stephendiehl.com/hask/index.html 2. PDF Version ­ http://dev.stephendiehl.com/hask/tutorial.pdf 3. EPUB Version ­ http://dev.stephendiehl.com/hask/tutorial.epub 4. Kindle Version ­ http://dev.stephendiehl.com/hask/tutorial.mobi Pull requests are always accepted for fixes and additional content. The only way this document will stayupto date and accurate through the kindness of readers like you and community patches and pull requests on Github. https://github.com/sdiehl/wiwinwlh Publish Date: March 3, 2020 Git Commit: 77482103ff953a8f189a050c4271919846a56612 Author This text is authored by Stephen Diehl. 1. Web: www.stephendiehl.com 2. Twitter: https://twitter.com/smdiehl 3. Github: https://github.com/sdiehl Special thanks to Erik Aker for copyediting assistance. Copyright © 2009­2020 Stephen Diehl This code included in the text is dedicated to the public domain. You can copy, modify, distribute and perform thecode, even for commercial purposes, all without asking permission. You may distribute this text in its full form freely, but may not reauthor or sublicense this work. Any reproductions of major portions of the text must include attribution. The software is provided ”as is”, without warranty of any kind, express or implied, including But not limitedtothe warranties of merchantability, fitness for a particular purpose and noninfringement. In no event shall the authorsor copyright holders be liable for any claim, damages or other liability, whether in an action of contract, tort or otherwise, Arising from, out of or in connection with the software or the use or other dealings in the software.
  • NU-Prolog Reference Manual

    NU-Prolog Reference Manual

    NU-Prolog Reference Manual Version 1.5.24 edited by James A. Thom & Justin Zobel Technical Report 86/10 Machine Intelligence Project Department of Computer Science University of Melbourne (Revised November 1990) Copyright 1986, 1987, 1988, Machine Intelligence Project, The University of Melbourne. All rights reserved. The Technical Report edition of this publication is given away free subject to the condition that it shall not, by the way of trade or otherwise, be lent, resold, hired out, or otherwise circulated, without the prior consent of the Machine Intelligence Project at the University of Melbourne, in any form or cover other than that in which it is published and without a similar condition including this condition being imposed on the subsequent user. The Machine Intelligence Project makes no representations or warranties with respect to the contents of this document and specifically disclaims any implied warranties of merchantability or fitness for any particular purpose. Furthermore, the Machine Intelligence Project reserves the right to revise this document and to make changes from time to time in its content without being obligated to notify any person or body of such revisions or changes. The usual codicil that no part of this publication may be reproduced, stored in a retrieval system, used for wrapping fish, or transmitted, in any form or by any means, electronic, mechanical, photocopying, paper dart, recording, or otherwise, without someone's express permission, is not imposed. Enquiries relating to the acquisition of NU-Prolog should be made to NU-Prolog Distribution Manager Machine Intelligence Project Department of Computer Science The University of Melbourne Parkville, Victoria 3052 Australia Telephone: (03) 344 5229.
  • Idris: a Functional Programming Language with Dependent Types

    Idris: a Functional Programming Language with Dependent Types

    Programming Languages and Compiler Construction Department of Computer Science Christian-Albrechts-University of Kiel Seminar Paper Idris: A Functional Programming Language with Dependent Types Author: B.Sc. Finn Teegen Date: 20th February 2015 Advised by: M.Sc. Sandra Dylus Contents 1 Introduction1 2 Fundamentals2 2.1 Universes....................................2 2.2 Type Families..................................2 2.3 Dependent Types................................3 2.4 Curry-Howard Correspondence........................4 3 Language Overview5 3.1 Simple Types and Functions..........................5 3.2 Dependent Types and Functions.......................6 3.3 Implicit Arguments...............................7 3.4 Views......................................8 3.5 Lazy Evaluation................................8 3.6 Syntax Extensions...............................9 4 Theorem Proving 10 4.1 Propositions as Types and Terms as Proofs................. 10 4.2 Encoding Intuitionistic First-Order Logic................... 12 4.3 Totality Checking................................ 14 5 Conclusion 15 ii 1 Introduction In conventional Hindley-Milner based programming languages, such as Haskell1, there is typically a clear separation between values and types. In dependently typed languages, however, this distinction is less clear or rather non-existent. In fact, types can depend on arbitrary values. Thus, they become first-class citizens and are computable like any other value. With types being allowed to contain values, they gain the possibility to describe prop- erties of their own elements. The standard example for dependent types is the type of lists of a given length - commonly referred to as vectors - where the length is part of the type itself. When starting to encode properties of values as types, the elements of such types can be seen as proofs that the stated property is true.
  • Variable-Arity Generic Interfaces

    Variable-Arity Generic Interfaces

    Variable-Arity Generic Interfaces T. Stephen Strickland, Richard Cobbe, and Matthias Felleisen College of Computer and Information Science Northeastern University Boston, MA 02115 [email protected] Abstract. Many programming languages provide variable-arity func- tions. Such functions consume a fixed number of required arguments plus an unspecified number of \rest arguments." The C++ standardiza- tion committee has recently lifted this flexibility from terms to types with the adoption of a proposal for variable-arity templates. In this paper we propose an extension of Java with variable-arity interfaces. We present some programming examples that can benefit from variable-arity generic interfaces in Java; a type-safe model of such a language; and a reduction to the core language. 1 Introduction In April of 2007 the C++ standardization committee adopted Gregor and J¨arvi's proposal [1] for variable-length type arguments in class templates, which pre- sented the idea and its implementation but did not include a formal model or soundness proof. As a result, the relevant constructs will appear in the upcom- ing C++09 draft. Demand for this feature is not limited to C++, however. David Hall submitted a request for variable-arity type parameters for classes to Sun in 2005 [2]. For an illustration of the idea, consider the remarks on first-class functions in Scala [3] from the language's homepage. There it says that \every function is a value. Scala provides a lightweight syntax for defining anonymous functions, it supports higher-order functions, it allows functions to be nested, and supports currying." To achieve this integration of objects and closures, Scala's standard library pre-defines ten interfaces (traits) for function types, which we show here in Java-like syntax: interface Function0<Result> { Result apply(); } interface Function1<Arg1,Result> { Result apply(Arg1 a1); } interface Function2<Arg1,Arg2,Result> { Result apply(Arg1 a1, Arg2 a2); } ..
  • Small Hitting-Sets for Tiny Arithmetic Circuits Or: How to Turn Bad Designs Into Good

    Small Hitting-Sets for Tiny Arithmetic Circuits Or: How to Turn Bad Designs Into Good

    Electronic Colloquium on Computational Complexity, Report No. 35 (2017) Small hitting-sets for tiny arithmetic circuits or: How to turn bad designs into good Manindra Agrawal ∗ Michael Forbes† Sumanta Ghosh ‡ Nitin Saxena § Abstract Research in the last decade has shown that to prove lower bounds or to derandomize polynomial identity testing (PIT) for general arithmetic circuits it suffices to solve these questions for restricted circuits. In this work, we study the smallest possibly restricted class of circuits, in particular depth-4 circuits, which would yield such results for general circuits (that is, the complexity class VP). We show that if we can design poly(s)-time hitting-sets for Σ ∧a ΣΠO(log s) circuits of size s, where a = ω(1) is arbitrarily small and the number of variables, or arity n, is O(log s), then we can derandomize blackbox PIT for general circuits in quasipolynomial time. Further, this establishes that either E6⊆#P/poly or that VP6=VNP. We call the former model tiny diagonal depth-4. Note that these are merely polynomials with arity O(log s) and degree ω(log s). In fact, we show that one only needs a poly(s)-time hitting-set against individual-degree a′ = ω(1) polynomials that are computable by a size-s arity-(log s) ΣΠΣ circuit (note: Π fanin may be s). Alternatively, we claim that, to understand VP one only needs to find hitting-sets, for depth-3, that have a small parameterized complexity. Another tiny family of interest is when we restrict the arity n = ω(1) to be arbitrarily small.
  • Making a Faster Curry with Extensional Types

    Making a Faster Curry with Extensional Types

    Making a Faster Curry with Extensional Types Paul Downen Simon Peyton Jones Zachary Sullivan Microsoft Research Zena M. Ariola Cambridge, UK University of Oregon [email protected] Eugene, Oregon, USA [email protected] [email protected] [email protected] Abstract 1 Introduction Curried functions apparently take one argument at a time, Consider these two function definitions: which is slow. So optimizing compilers for higher-order lan- guages invariably have some mechanism for working around f1 = λx: let z = h x x in λy:e y z currying by passing several arguments at once, as many as f = λx:λy: let z = h x x in e y z the function can handle, which is known as its arity. But 2 such mechanisms are often ad-hoc, and do not work at all in higher-order functions. We show how extensional, call- It is highly desirable for an optimizing compiler to η ex- by-name functions have the correct behavior for directly pand f1 into f2. The function f1 takes only a single argu- expressing the arity of curried functions. And these exten- ment before returning a heap-allocated function closure; sional functions can stand side-by-side with functions native then that closure must subsequently be called by passing the to practical programming languages, which do not use call- second argument. In contrast, f2 can take both arguments by-name evaluation. Integrating call-by-name with other at once, without constructing an intermediate closure, and evaluation strategies in the same intermediate language ex- this can make a huge difference to run-time performance in presses the arity of a function in its type and gives a princi- practice [Marlow and Peyton Jones 2004].
  • Lambda-Calculus Types and Models

    Lambda-Calculus Types and Models

    Jean-Louis Krivine LAMBDA-CALCULUS TYPES AND MODELS Translated from french by René Cori To my daughter Contents Introduction5 1 Substitution and beta-conversion7 Simple substitution ..............................8 Alpha-equivalence and substitution ..................... 12 Beta-conversion ................................ 18 Eta-conversion ................................. 24 2 Representation of recursive functions 29 Head normal forms .............................. 29 Representable functions ............................ 31 Fixed point combinators ........................... 34 The second fixed point theorem ....................... 37 3 Intersection type systems 41 System D­ ................................... 41 System D .................................... 50 Typings for normal terms ........................... 54 4 Normalization and standardization 61 Typings for normalizable terms ........................ 61 Strong normalization ............................. 68 ¯I-reduction ................................. 70 The ¸I-calculus ................................ 72 ¯´-reduction ................................. 74 The finite developments theorem ....................... 77 The standardization theorem ......................... 81 5 The Böhm theorem 87 3 4 CONTENTS 6 Combinatory logic 95 Combinatory algebras ............................. 95 Extensionality axioms ............................. 98 Curry’s equations ............................... 101 Translation of ¸-calculus ........................... 105 7 Models of lambda-calculus 111 Functional
  • Constrained Type Families (Extended Version)

    Constrained Type Families (Extended Version)

    Constrained Type Families (extended version) J. GARRETT MORRIS, e University of Edinburgh and e University of Kansas 42 RICHARD A. EISENBERG, Bryn Mawr College We present an approach to support partiality in type-level computation without compromising expressiveness or type safety. Existing frameworks for type-level computation either require totality or implicitly assume it. For example, type families in Haskell provide a powerful, modular means of dening type-level computation. However, their current design implicitly assumes that type families are total, introducing nonsensical types and signicantly complicating the metatheory of type families and their extensions. We propose an alternative design, using qualied types to pair type-level computations with predicates that capture their domains. Our approach naturally captures the intuitive partiality of type families, simplifying their metatheory. As evidence, we present the rst complete proof of consistency for a language with closed type families. CCS Concepts: •eory of computation ! Type structures; •So ware and its engineering ! Func- tional languages; Additional Key Words and Phrases: Type families, Type-level computation, Type classes, Haskell ACM Reference format: J. Garre Morris and Richard A. Eisenberg. 2017. Constrained Type Families (extended version). PACM Progr. Lang. 1, 1, Article 42 (January 2017), 38 pages. DOI: hp://dx.doi.org/10.1145/3110286 1 INTRODUCTION Indexed type families (Chakravarty et al. 2005; Schrijvers et al. 2008) extend the Haskell type system with modular type-level computation. ey allow programmers to dene and use open mappings from types to types. ese have given rise to further extensions of the language, such as closed type families (Eisenberg et al.
  • Decompositions of Functions Based on Arity

    Decompositions of Functions Based on Arity

    DECOMPOSITIONS OF FUNCTIONS BASED ON ARITY GAP MIGUEL COUCEIRO, ERKKO LEHTONEN, AND TAMAS´ WALDHAUSER1 Abstract. We study the arity gap of functions of several variables defined on an arbitrary set A and valued in another set B. The arity gap of such a function is the minimum decrease in the number of essential variables when variables are identified. We establish a complete classification of functions according to their arity gap, extending existing results for finite functions. This classification is refined when the codomain B has a group structure, by providing unique decompositions into sums of functions of a prescribed form. As an application of the unique decompositions, in the case of finite sets we count, for each n and p, the number of n-ary functions that depend on all of their variables and have arity gap p. 1. Introduction Essential variables of functions have been investigated in multiple-valued logic and computer science, especially, concerning the distribution of values of functions whose variables are all essential (see, e.g., [9, 16, 22]), the process of substituting constants for variables (see, e.g., [2, 3, 14, 16, 18]), and the process of substituting variables for variables (see, e.g., [5, 10, 16, 21]). The latter line of study goes back to the 1963 paper by Salomaa [16] who consid- ered the following problem: How does identification of variables affect the number of essential variables of a given function? The minimum decrease in the number of essential variables of a function f : An → B (n ≥ 2) which depends on all of its variables is called the arity gap of f.
  • Twelf User's Guide

    Twelf User's Guide

    Twelf User’s Guide Version 1.4 Frank Pfenning and Carsten Schuermann Copyright c 1998, 2000, 2002 Frank Pfenning and Carsten Schuermann Chapter 1: Introduction 1 1 Introduction Twelf is the current version of a succession of implementations of the logical framework LF. Previous systems include Elf (which provided type reconstruction and the operational semantics reimplemented in Twelf) and MLF (which implemented module-level constructs loosely based on the signatures and functors of ML still missing from Twelf). Twelf should be understood as research software. This means comments, suggestions, and bug reports are extremely welcome, but there are no guarantees regarding response times. The same remark applies to these notes which constitute the only documentation on the present Twelf implementation. For current information including download instructions, publications, and mailing list, see the Twelf home page at http://www.cs.cmu.edu/~twelf/. This User’s Guide is pub- lished as Frank Pfenning and Carsten Schuermann Twelf User’s Guide Technical Report CMU-CS-98-173, Department of Computer Science, Carnegie Mellon University, November 1998. Below we state the typographic conventions in this manual. code for Twelf or ML code ‘samp’ for characters and small code fragments metavar for placeholders in code keyboard for input in verbatim examples hkeyi for keystrokes math for mathematical expressions emph for emphasized phrases File names for examples given in this guide are relative to the main directory of the Twelf installation. For example ‘examples/guide/nd.elf’ may be found in ‘/usr/local/twelf/examples/guide/nd.elf’ if Twelf was installed into the ‘/usr/local/’ directory.