DOCSLIB.ORG

Basics of Type Theory and Coq Logic Types ∧, ∨, ⇒, ¬, ∀, ∃ ×, +, →, Q, P Michael Shulman

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Basics of Type Theory and Coq Logic Types ∧, ∨, ⇒, ¬, ∀, ∃ ×, +, →, Q, P Michael Shulman Type-theoretic foundations Set theory Type theory Basics of type theory and Coq Logic Types ^; _; ); :; 8; 9 ×; +; !; Q; P Michael Shulman Sets Logic January 31, 2012 ×; +; !; Q; P ^; _; ); :; 8; 9 x 2 A is a proposition x : A is a typing judgment 1 / 77 2 / 77 Type theory is programming Typing judgments Type theory consists of rules for manipulating judgments. The most important judgment is a typing judgment: x1 : A1; x2 : A2;::: xn : An ` b : B For now, think of type theory as a programming language. The turnstile ` binds most loosely, followed by commas. • Closely related to functional programming languages like This should be read as: ML, Haskell, Lisp, Scheme. In the context of variables x of type A , x of type A ,..., • More expressive and powerful. 1 1 2 2 and xn of type An, the expression b has type B. • Can manipulate “mathematical objects”. Examples ` 0: N x : N; y : N ` x + y : N f : R ! R; x : R ` f (x): R 1 (n) 1 f : C (R; R); n: N ` f : C (R; R) 4 / 77 5 / 77 Type constructors Derivations The basic rules tell us how to construct valid typing judgments, We write these rules as follows. i.e. how to write programs with given input and output types. This includes: ` A: Type ` B : Type 1 How to construct new types (judgments Γ ` A: Type). ` A ! B : Type 2 How to construct terms of these types. 3 How to use such terms to construct terms of other types. x : A ` b : B A Example (Function types) ` λx :b : A ! B 1 If A: Type and B : Type, then A ! B : Type. ` f : A ! B ` a: A 2 If x : A ` b : B, then λxA:b : A ! B. ` f (a): B 3 If a: A and f : A ! B, then f (a): B. 6 / 77 7 / 77 Derivations in Context Type theory as programming This is just a mathematical syntax for programming. More generally, we allow an arbitrary context Γ = (x1 : A1;:::; xn : An) of typed variables. int square(int x) { return (x * x); } Γ ` A: Type Γ ` B : Type def square(x): Γ ` A ! B : Type return (x * x) square :: Int -> Int Γ; x : A ` b : B introduction square x = x * x Γ ` λxA:b : A ! B fun square (n:int):int = n * n Γ ` f : A ! B Γ ` a: A elimination (define (square n) ( n n)) Γ ` f (a): B * square := λxZ:(x ∗ x) 8 / 77 9 / 77 Evaluation Functions of many variables The rules also tell us how to evaluate or compute terms. The general rule is: A function of two variables can be represented as a function of • introduction plus elimination computes to substitution. one variable which returns a function of another variable. foo := λxZ: λy Z:(2 ∗ x + y ∗ y) Γ; x : A ` b : B Γ ` a: A Γ ` (λxA:b)(a) ! b[a=x] β foo(3)(1) !β λy Z:(2 ∗ x + y ∗ y) [3=x](1) Here b[a=x] means b with a substituted for x. ≡ λy Z:(2 ∗ 3 + y ∗ y) (1) !β (2 ∗ 3 + y ∗ y)[1=y] For historical reasons, this is called β-reduction. ≡ (2 ∗ 3 + 1 ∗ 1) Z This is called currying (after Haskell Curry). square(2) ≡ (λx :(x ∗ x))(2) !β (x ∗ x)[2=x] ≡ 2 ∗ 2 10 / 77 12 / 77 Functions of many variables Another example: disjoint unions A simplified notation for abstractions: foo := λxZ: λy Z:(2 ∗ x + y ∗ y) Γ ` A: Type Γ ` B : Type ≡ λxZy Z:(2 ∗ x + y ∗ y) Γ ` A + B : Type And for types, ! associates to the right: A ! B ! C means A ! (B ! C) Γ ` a: A Γ ` b : B Γ ` inl(a): A + B Γ ` inr(b): A + B And for application: Γ ` C : Type foo(3)(1) foo 3 1 Γ ` p : A + B Γ; x : A ` cA : C Γ; y : B ` cB : C That is, juxtaposition means application, which associates to A B Γ ` case(p; x :cA; y :cB): C the left: foo 3 1 means (foo 3) 1 13 / 77 15 / 77 Case switching Evaluating case switches Γ ` C : Type Γ ` p : A + B Γ; x : A ` cA : C Γ; y : B ` cB : C A B Γ ` C : Type Γ ` p : A + B Γ ` case(p; x :cA; y :cB): C Γ; x : A ` cA : C Γ; y : B ` cB : C Γ ` a: A switch(p) { A B Γ ` case(inl(a); x :c ; y :c ) !β c [a=x] if p is inl(x): A B A do cA with x if p is inr(y): Γ ` C : Type Γ ` p : A + B do cB with y Γ; x : A ` cA : C Γ; y : B ` cB : C Γ ` b : B A B } Γ ` case(inr(b); x :cA; y :cB) !β cB[b=y] Don’t worry about the exact syntax of “case”. Everyone does it differently, and we’ll mostly use Coq’s syntax (later). 16 / 77 17 / 77 The unit type Polarity Negative types Positive types Γ ` unit: Type Γ ` tt: unit A ! BA + B Q x : A B(x) A × B Γ ` p : unit Γ ` C : Type Γ ` c : C unit Γ ` triv(p; c): C empty P If we know how to produce a C using all the possible inputs that x : A B(x) can go into a unit, then we can produce a C from any unit. • A negative type is characterized by its eliminations. Γ ` C : Type Γ ` c : C 1 We use a term by applying it. 2 We construct a term by saying what it does when applied. Γ ` triv(tt; c) !β c • A positive type is characterized by its introductions. When we evaluate the eliminator on a term of canonical form, 1 We construct a term with a constructor. we obtain the data that went into the eliminator associated to 2 We use a term by saying what to do with each constructor. that form. 19 / 77 21 / 77 Polarity Types in Coq Negative types Positive types Coq uses a type theory called the predicative Calculus of (co)Inductive Constructions. There are only four ways to A ! BA + B construct types in Coq. Q x : A B(x) A × B unit 1 Dependent product (negative). • Includes A ! B as a special case; more later empty • Constructed with fun x => ... P x : A B(x) • Applied with juxtaposition f x 2 Inductive type families (positive). • Built with constructors like inl, inr, tt. NB: This is an oversimplification; some or all of these “positive • Eliminated with match. types” could also be presented negatively. But for us, they will • More details later. be positive. 3 Universes (sorts) like Type (unpolarized). 4 Coinductive type families (negative). 21 / 77 22 / 77 Exercise #1 Projections Exercise Define the cartesian product A × B as a positive type. Γ ` A: Type Γ ` B : Type For p : A × B: Γ ` A × B : Type fst(p) := unpack(p; xA y B:x): A Γ ` a: A Γ ` b : B Γ ` (a; b): A × B snd(p) := unpack(p; xA y B:y): B Γ ` C : Type Γ ` p : A × B Γ; x : A; y : B ` c : C Γ ` unpack(p; xA y B:c): C Γ ` C : Type Γ ` a: A Γ ` b : B Γ; x : A; y : B ` c : C Γ ` unpack((a; b); xA y B:c) ! c[a=x; b=y] β 23 / 77 24 / 77 Exercise #2 Structural rules Exercise Define the empty type ; as a positive type. We also need a few rules for “how to get going” with typing judgments. Γ ` A: Type Γ ` ;: Type start (x 2= Γ) Γ; x : A ` x : A (no introduction rule) Γ ` A: Type Γ ` b : B weakening (x 2= Γ) Γ; x : A ` b : B Γ ` p : ; Γ ` C : Type Γ ` a: A Γ ` A $β B Γ ` abort(p): C conversion Γ ` a: B (no computation rule) ($β is the equivalence relation generated by !β) 26 / 77 28 / 77 Now you know something! Logic in the style of type theory We can also read a typing judgment Definition The structural rules plus the type constructor ! (and nothing x1 : P1;:::; xn : Pn ` q : Q else) form the simply typed lambda calculus“ λ!”. as a truth judgment We can of course add other constructors. Sometimes people Under hypotheses P1, P2,..., Pn, write λ×→ for λ! with cartesian products and unit, etc. the conclusion Q is provable. 29 / 77 31 / 77 Logical connectives Implication The basic rules tell us how to construct valid truth judgments. To emphasize this viewpoint, we write Prop rather than Type. This includes: Γ ` P : Prop Γ ` Q : Prop 1 How to construct new propositions. Γ ` (P ) Q): Prop 2 How to prove such propositions. 3 How to use such propositions to prove other propositions. Γ; x : P ` q : Q Example (Implication) Γ ` λxP :q : P ) Q 1 If P and Q are propositions, then so is P ) Q. 2 If assuming P, we can prove Q, then we can prove P ) Q. Γ ` f : P ) Q Γ ` p : P 3 If we can prove P and P ) Q, then we can prove Q. Γ ` f (p): Q 32 / 77 33 / 77 Conjunction Disjunction _ (P ^ Q means “P and Q”) (P Q means “P or Q”) Γ ` : Γ ` : Γ ` P : Prop Γ ` Q : Prop P Prop Q Prop Γ ` ( _ ): Γ ` (P ^ Q): Prop P Q Prop Γ ` : Γ ` : Γ ` p : P Γ ` q : Q p P q Q Γ ` ( ): _ Γ ` ( ): _ Γ ` (p; q): P ^ Q inl p P Q inr q P Q Γ ` : Γ ` R : Prop Γ ` s : P ^ Q Γ; x : P; y : Q ` r : R R Prop Γ ` s : P _ Q Γ; x : P ` r : R Γ; y : Q ` r : R P Q P Q Γ ` unpack(s; x y :r): R P Q Γ ` case(s; x :rP ; y :rQ): R 34 / 77 35 / 77 Propositions as types Proof terms a.k.a.
Load more

Recommended publications
  • Tt-Satisfiable
    CMPSCI 601: Recall From Last Time Lecture 6 Boolean Syntax: ¡ ¢¤£¦¥¨§¨£ © §¨£ § Boolean variables: A boolean variable represents an atomic statement that may be either true or false. There may be infinitely many of these available. Boolean expressions: £ atomic: , (“top”), (“bottom”) § ! " # $ , , , , , for Boolean expressions Note that any particular expression is a finite string, and thus may use only finitely many variables. £ £ A literal is an atomic expression or its negation: , , , . As you may know, the choice of operators is somewhat arbitary as long as we have a complete set, one that suf- fices to simulate all boolean functions. On HW#1 we ¢ § § ! argued that is already a complete set. 1 CMPSCI 601: Boolean Logic: Semantics Lecture 6 A boolean expression has a meaning, a truth value of true or false, once we know the truth values of all the individual variables. ¢ £ # ¡ A truth assignment is a function ¢ true § false , where is the set of all variables. An as- signment is appropriate to an expression ¤ if it assigns a value to all variables used in ¤ . ¡ The double-turnstile symbol ¥ (read as “models”) de- notes the relationship between a truth assignment and an ¡ ¥ ¤ expression. The statement “ ” (read as “ models ¤ ¤ ”) simply says “ is true under ”. 2 ¡ ¤ ¥ ¤ If is appropriate to , we define when is true by induction on the structure of ¤ : is true and is false for any , £ A variable is true iff says that it is, ¡ ¡ ¡ ¡ " ! ¥ ¤ ¥ ¥ If ¤ , iff both and , ¡ ¡ ¡ ¡ " ¥ ¤ ¥ ¥ If ¤ , iff either or or both, ¡ ¡ ¡ ¡ " # ¥ ¤ ¥ ¥ If ¤ , unless and , ¡ ¡ ¡ ¡ $ ¥ ¤ ¥ ¥ If ¤ , iff and are both true or both false. 3 Definition 6.1 A boolean expression ¤ is satisfiable iff ¡ ¥ ¤ there exists .
    [Show full text]
  • Experience Implementing a Performant Category-Theory Library in Coq
    Experience Implementing a Performant Category-Theory Library in Coq Jason Gross, Adam Chlipala, and David I. Spivak Massachusetts Institute of Technology, Cambridge, MA, USA [email protected], [email protected], [email protected] Abstract. We describe our experience implementing a broad category- theory library in Coq. Category theory and computational performance are not usually mentioned in the same breath, but we have needed sub- stantial engineering effort to teach Coq to cope with large categorical constructions without slowing proof script processing unacceptably. In this paper, we share the lessons we have learned about how to repre- sent very abstract mathematical objects and arguments in Coq and how future proof assistants might be designed to better support such rea- soning. One particular encoding trick to which we draw attention al- lows category-theoretic arguments involving duality to be internalized in Coq's logic with definitional equality. Ours may be the largest Coq development to date that uses the relatively new Coq version developed by homotopy type theorists, and we reflect on which new features were especially helpful. Keywords: Coq · category theory · homotopy type theory · duality · performance 1 Introduction Category theory [36] is a popular all-encompassing mathematical formalism that casts familiar mathematical ideas from many domains in terms of a few unifying concepts. A category can be described as a directed graph plus algebraic laws stating equivalences between paths through the graph. Because of this spar- tan philosophical grounding, category theory is sometimes referred to in good humor as \formal abstract nonsense." Certainly the popular perception of cat- egory theory is quite far from pragmatic issues of implementation.
    [Show full text]
  • ECSS-E-TM-40-07 Volume 2A 25 January 2011
    ECSS-E-TM-40-07 Volume 2A 25 January 2011 Space engineering Simulation modelling platform - Volume 2: Metamodel ECSS Secretariat ESA-ESTEC Requirements & Standards Division Noordwijk, The Netherlands ECSS‐E‐TM‐40‐07 Volume 2A 25 January 2011 Foreword This document is one of the series of ECSS Technical Memoranda. Its Technical Memorandum status indicates that it is a non‐normative document providing useful information to the space systems developers’ community on a specific subject. It is made available to record and present non‐normative data, which are not relevant for a Standard or a Handbook. Note that these data are non‐normative even if expressed in the language normally used for requirements. Therefore, a Technical Memorandum is not considered by ECSS as suitable for direct use in Invitation To Tender (ITT) or business agreements for space systems development. Disclaimer ECSS does not provide any warranty whatsoever, whether expressed, implied, or statutory, including, but not limited to, any warranty of merchantability or fitness for a particular purpose or any warranty that the contents of the item are error‐free. In no respect shall ECSS incur any liability for any damages, including, but not limited to, direct, indirect, special, or consequential damages arising out of, resulting from, or in any way connected to the use of this document, whether or not based upon warranty, business agreement, tort, or otherwise; whether or not injury was sustained by persons or property or otherwise; and whether or not loss was sustained from, or arose out of, the results of, the item, or any services that may be provided by ECSS.
    [Show full text]
  • Chapter 9: Initial Theorems About Axiom System
    Initial Theorems about Axiom 9 System AS1 1. Theorems in Axiom Systems versus Theorems about Axiom Systems ..................................2 2. Proofs about Axiom Systems ................................................................................................3 3. Initial Examples of Proofs in the Metalanguage about AS1 ..................................................4 4. The Deduction Theorem.......................................................................................................7 5. Using Mathematical Induction to do Proofs about Derivations .............................................8 6. Setting up the Proof of the Deduction Theorem.....................................................................9 7. Informal Proof of the Deduction Theorem..........................................................................10 8. The Lemmas Supporting the Deduction Theorem................................................................11 9. Rules R1 and R2 are Required for any DT-MP-Logic........................................................12 10. The Converse of the Deduction Theorem and Modus Ponens .............................................14 11. Some General Theorems About ......................................................................................15 12. Further Theorems About AS1.............................................................................................16 13. Appendix: Summary of Theorems about AS1.....................................................................18 2 Hardegree,
    [Show full text]
  • Testing Noninterference, Quickly
    Testing Noninterference, Quickly Cat˘ alin˘ Hrit¸cu1 John Hughes2 Benjamin C. Pierce1 Antal Spector-Zabusky1 Dimitrios Vytiniotis3 Arthur Azevedo de Amorim1 Leonidas Lampropoulos1 1University of Pennsylvania 2Chalmers University 3Microsoft Research Abstract To answer this question, we take as a case study the task of Information-flow control mechanisms are difficult to design and extending a simple abstract stack-and-pointer machine to track dy- labor intensive to prove correct. To reduce the time wasted on namic information flow and enforce termination-insensitive nonin- proof attempts doomed to fail due to broken definitions, we ad- terference [23]. Although our machine is simple, this exercise is vocate modern random testing techniques for finding counterexam- both nontrivial and novel. While simpler notions of dynamic taint ples during the design process. We show how to use QuickCheck, tracking are well studied for both high- and low-level languages, a property-based random-testing tool, to guide the design of a sim- it has only recently been shown [1, 24] that dynamic checks are ple information-flow abstract machine. We find that both sophis- capable of soundly enforcing strong security properties. Moreover, ticated strategies for generating well-distributed random programs sound dynamic IFC has been studied only in the context of lambda- and readily falsifiable formulations of noninterference properties calculi [1, 16, 25] and While programs [24]; the unstructured con- are critically important. We propose several approaches and eval- trol flow of a low-level machine poses additional challenges. (Test- uate their effectiveness on a collection of injected bugs of varying ing of static IFC mechanisms is left as future work.) subtlety.
    [Show full text]
  • An Anti-Locally-Nameless Approach to Formalizing Quantifiers Olivier Laurent
    An Anti-Locally-Nameless Approach to Formalizing Quantifiers Olivier Laurent To cite this version: Olivier Laurent. An Anti-Locally-Nameless Approach to Formalizing Quantifiers. Certified Programs and Proofs, Jan 2021, virtual, Denmark. pp.300-312, 10.1145/3437992.3439926. hal-03096253 HAL Id: hal-03096253 https://hal.archives-ouvertes.fr/hal-03096253 Submitted on 4 Jan 2021 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. An Anti-Locally-Nameless Approach to Formalizing Quantifiers Olivier Laurent Univ Lyon, EnsL, UCBL, CNRS, LIP LYON, France [email protected] Abstract all cases have been covered. This works perfectly well for We investigate the possibility of formalizing quantifiers in various propositional systems, but as soon as (first-order) proof theory while avoiding, as far as possible, the use of quantifiers enter the picture, we have to face one ofthe true binding structures, α-equivalence or variable renam- nightmares of formalization: quantifiers are binders... The ings. We propose a solution with two kinds of variables in question of the formalization of binders does not yet have an 1 terms and formulas, as originally done by Gentzen. In this answer which makes perfect consensus .
    [Show full text]
  • Bidirectional Typing
    Bidirectional Typing JANA DUNFIELD, Queen’s University, Canada NEEL KRISHNASWAMI, University of Cambridge, United Kingdom Bidirectional typing combines two modes of typing: type checking, which checks that a program satisfies a known type, and type synthesis, which determines a type from the program. Using checking enables bidirectional typing to support features for which inference is undecidable; using synthesis enables bidirectional typing to avoid the large annotation burden of explicitly typed languages. In addition, bidirectional typing improves error locality. We highlight the design principles that underlie bidirectional type systems, survey the development of bidirectional typing from the prehistoric period before Pierce and Turner’s local type inference to the present day, and provide guidance for future investigations. ACM Reference Format: Jana Dunfield and Neel Krishnaswami. 2020. Bidirectional Typing. 1, 1 (November 2020), 37 pages. https: //doi.org/10.1145/nnnnnnn.nnnnnnn 1 INTRODUCTION Type systems serve many purposes. They allow programming languages to reject nonsensical programs. They allow programmers to express their intent, and to use a type checker to verify that their programs are consistent with that intent. Type systems can also be used to automatically insert implicit operations, and even to guide program synthesis. Automated deduction and logic programming give us a useful lens through which to view type systems: modes [Warren 1977]. When we implement a typing judgment, say Γ ` 4 : 퐴, is each of the meta-variables (Γ, 4, 퐴) an input, or an output? If the typing context Γ, the term 4 and the type 퐴 are inputs, we are implementing type checking. If the type 퐴 is an output, we are implementing type inference.
    [Show full text]
  • Programming with Gadts
    Chapter 8 Programming with GADTs ML-style variants and records make it possible to define many different data types, including many of the types we encoded in System F휔 in Chapter 2.4.1: booleans, sums, lists, trees, and so on. However, types defined this way can lead to an error-prone programming style. For example, the OCaml standard library includes functions List .hd and List . tl for accessing the head and tail of a list: val hd : ’ a l i s t → ’ a val t l : ’ a l i s t → ’ a l i s t Since the types of hd and tl do not express the requirement that the argu- ment lists be non-empty, the functions can be called with invalid arguments, leading to run-time errors: # List.hd [];; Exception: Failure ”hd”. In this chapter we introduce generalized algebraic data types (GADTs), which support richer types for data and functions, avoiding many of the errors that arise with partial functions like hd. As we shall see, GADTs offer a num- ber of benefits over simple ML-style types, including the ability to describe the shape of data more precisely, more informative applications of the propositions- as-types correspondence, and opportunities for the compiler to generate more efficient code. 8.1 Generalising algebraic data types Towards the end of Chapter 2 we considered some different approaches to defin- ing binary branching tree types. Under the following definition a tree is either empty, or consists of an element of type ’a and a pair of trees: type ’ a t r e e = Empty : ’ a t r e e | Tree : ’a tree * ’a * ’a tree → ’ a t r e e 59 60 CHAPTER 8.
    [Show full text]
  • Mathematics in the Computer
    Mathematics in the Computer Mario Carneiro Carnegie Mellon University April 26, 2021 1 / 31 Who am I? I PhD student in Logic at CMU I Proof engineering since 2013 I Metamath (maintainer) I Lean 3 (maintainer) I Dabbled in Isabelle, HOL Light, Coq, Mizar I Metamath Zero (author) Github: digama0 I Proved 37 of Freek’s 100 theorems list in Zulip: Mario Carneiro Metamath I Lots of library code in set.mm and mathlib I Say hi at https://leanprover.zulipchat.com 2 / 31 I Found Metamath via a random internet search I they already formalized half of the book! I .! . and there is some stuff on cofinality they don’t have yet, maybe I can help I Got involved, did it as a hobby for a few years I Got a job as an android developer, kept on the hobby I Norm Megill suggested that I submit to a (Mizar) conference, it went well I Met Leo de Moura (Lean author) at a conference, he got me in touch with Jeremy Avigad (my current advisor) I Now I’m a PhD at CMU philosophy! How I got involved in formalization I Undergraduate at Ohio State University I Math, CS, Physics I Reading Takeuti & Zaring, Axiomatic Set Theory 3 / 31 I they already formalized half of the book! I .! . and there is some stuff on cofinality they don’t have yet, maybe I can help I Got involved, did it as a hobby for a few years I Got a job as an android developer, kept on the hobby I Norm Megill suggested that I submit to a (Mizar) conference, it went well I Met Leo de Moura (Lean author) at a conference, he got me in touch with Jeremy Avigad (my current advisor) I Now I’m a PhD at CMU philosophy! How I got involved in formalization I Undergraduate at Ohio State University I Math, CS, Physics I Reading Takeuti & Zaring, Axiomatic Set Theory I Found Metamath via a random internet search 3 / 31 I .
    [Show full text]
  • Chapter 13: Formal Proofs and Quantifiers
    Chapter 13: Formal Proofs and Quantifiers § 13.1 Universal quantifier rules Universal Elimination (∀ Elim) ∀x S(x) ❺ S(c) Here x stands for any variable, c stands for any individual constant, and S(c) stands for the result of replacing all free occurrences of x in S(x) with c. Example 1. ∀x ∃y (Adjoins(x, y) ∧ SameSize(y, x)) 2. ∃y (Adjoins(b, y) ∧ SameSize(y, b)) ∀ Elim: 1 General Conditional Proof (∀ Intro) ✾c P(c) Where c does not occur outside Q(c) the subproof where it is introduced. ❺ ∀x (P(x) → Q(x)) There is an important bit of new notation here— ✾c , the “boxed constant” at the beginning of the assumption line. This says, in effect, “let’s call it c.” To enter the boxed constant in Fitch, start a new subproof and click on the downward pointing triangle ❼. This will open a menu that lets you choose the constant you wish to use as a name for an arbitrary object. Your subproof will typically end with some sentence containing this constant. In giving the justification for the universal generalization, we cite the entire subproof (as we do in the case of → Intro). Notice that although c may not occur outside the subproof where it is introduced, it may occur again inside a subproof within the original subproof. Universal Introduction (∀ Intro) ✾c Where c does not occur outside the subproof where it is P(c) introduced. ❺ ∀x P(x) Remember, any time you set up a subproof for ∀ Intro, you must choose a “boxed constant” on the assumption line of the subproof, even if there is no sentence on the assumption line.
    [Show full text]
  • Scala by Example (2009)
    Scala By Example DRAFT January 13, 2009 Martin Odersky PROGRAMMING METHODS LABORATORY EPFL SWITZERLAND Contents 1 Introduction1 2 A First Example3 3 Programming with Actors and Messages7 4 Expressions and Simple Functions 11 4.1 Expressions And Simple Functions...................... 11 4.2 Parameters.................................... 12 4.3 Conditional Expressions............................ 15 4.4 Example: Square Roots by Newton’s Method................ 15 4.5 Nested Functions................................ 16 4.6 Tail Recursion.................................. 18 5 First-Class Functions 21 5.1 Anonymous Functions............................. 22 5.2 Currying..................................... 23 5.3 Example: Finding Fixed Points of Functions................ 25 5.4 Summary..................................... 28 5.5 Language Elements Seen So Far....................... 28 6 Classes and Objects 31 7 Case Classes and Pattern Matching 43 7.1 Case Classes and Case Objects........................ 46 7.2 Pattern Matching................................ 47 8 Generic Types and Methods 51 8.1 Type Parameter Bounds............................ 53 8.2 Variance Annotations.............................. 56 iv CONTENTS 8.3 Lower Bounds.................................. 58 8.4 Least Types.................................... 58 8.5 Tuples....................................... 60 8.6 Functions.................................... 61 9 Lists 63 9.1 Using Lists.................................... 63 9.2 Definition of class List I: First Order Methods..............
    [Show full text]
  • An Ontology-Based Semantic Foundation for Organizational Structure Modeling in the ARIS Method
    An Ontology-Based Semantic Foundation for Organizational Structure Modeling in the ARIS Method Paulo Sérgio Santos Jr., João Paulo A. Almeida, Giancarlo Guizzardi Ontology & Conceptual Modeling Research Group (NEMO) Computer Science Department, Federal University of Espírito Santo (UFES) Vitória, ES, Brazil [email protected]; [email protected]; [email protected] Abstract—This paper focuses on the issue of ontological Although present in most enterprise architecture interpretation for the ARIS organization modeling language frameworks, a semantic foundation for organizational with the following contributions: (i) providing real-world modeling elements is still lacking [1]. This is a significant semantics to the primitives of the language by using the UFO challenge from the perspective of modelers who must select foundational ontology as a semantic domain; (ii) the and manipulate modeling elements to describe an Enterprise identification of inappropriate elements of the language, using Architecture and from the perspective of stakeholders who a systematic ontology-based analysis approach; and (iii) will be exposed to models for validation and decision recommendations for improvements of the language to resolve making. In other words, a clear semantic account of the the issues identified. concepts underlying Enterprise Modeling languages is Keywords: semantics for enterprise models; organizational required for Enterprise Models to be used as a basis for the structure; ontological interpretation; ARIS; UFO (Unified management, design and evolution of an Enterprise Foundation Ontology) Architecture. In this paper we are particularly interested in the I. INTRODUCTION modeling of this architectural domain in the widely- The need to understand and manage the evolution of employed ARIS Method (ARchitecture for integrated complex organizations and its information systems has given Information Systems).
    [Show full text]