On Decidability of Nominal Subtyping with Variance
Total Page:16
File Type:pdf, Size:1020Kb
Load more
Recommended publications
-
“The Church-Turing “Thesis” As a Special Corollary of Gödel's
“The Church-Turing “Thesis” as a Special Corollary of Gödel’s Completeness Theorem,” in Computability: Turing, Gödel, Church, and Beyond, B. J. Copeland, C. Posy, and O. Shagrir (eds.), MIT Press (Cambridge), 2013, pp. 77-104. Saul A. Kripke This is the published version of the book chapter indicated above, which can be obtained from the publisher at https://mitpress.mit.edu/books/computability. It is reproduced here by permission of the publisher who holds the copyright. © The MIT Press The Church-Turing “ Thesis ” as a Special Corollary of G ö del ’ s 4 Completeness Theorem 1 Saul A. Kripke Traditionally, many writers, following Kleene (1952) , thought of the Church-Turing thesis as unprovable by its nature but having various strong arguments in its favor, including Turing ’ s analysis of human computation. More recently, the beauty, power, and obvious fundamental importance of this analysis — what Turing (1936) calls “ argument I ” — has led some writers to give an almost exclusive emphasis on this argument as the unique justification for the Church-Turing thesis. In this chapter I advocate an alternative justification, essentially presupposed by Turing himself in what he calls “ argument II. ” The idea is that computation is a special form of math- ematical deduction. Assuming the steps of the deduction can be stated in a first- order language, the Church-Turing thesis follows as a special case of G ö del ’ s completeness theorem (first-order algorithm theorem). I propose this idea as an alternative foundation for the Church-Turing thesis, both for human and machine computation. Clearly the relevant assumptions are justified for computations pres- ently known. -
Church's Thesis and the Conceptual Analysis of Computability
Church’s Thesis and the Conceptual Analysis of Computability Michael Rescorla Abstract: Church’s thesis asserts that a number-theoretic function is intuitively computable if and only if it is recursive. A related thesis asserts that Turing’s work yields a conceptual analysis of the intuitive notion of numerical computability. I endorse Church’s thesis, but I argue against the related thesis. I argue that purported conceptual analyses based upon Turing’s work involve a subtle but persistent circularity. Turing machines manipulate syntactic entities. To specify which number-theoretic function a Turing machine computes, we must correlate these syntactic entities with numbers. I argue that, in providing this correlation, we must demand that the correlation itself be computable. Otherwise, the Turing machine will compute uncomputable functions. But if we presuppose the intuitive notion of a computable relation between syntactic entities and numbers, then our analysis of computability is circular.1 §1. Turing machines and number-theoretic functions A Turing machine manipulates syntactic entities: strings consisting of strokes and blanks. I restrict attention to Turing machines that possess two key properties. First, the machine eventually halts when supplied with an input of finitely many adjacent strokes. Second, when the 1 I am greatly indebted to helpful feedback from two anonymous referees from this journal, as well as from: C. Anthony Anderson, Adam Elga, Kevin Falvey, Warren Goldfarb, Richard Heck, Peter Koellner, Oystein Linnebo, Charles Parsons, Gualtiero Piccinini, and Stewart Shapiro. I received extremely helpful comments when I presented earlier versions of this paper at the UCLA Philosophy of Mathematics Workshop, especially from Joseph Almog, D. -
Typescript Language Specification
TypeScript Language Specification Version 1.8 January, 2016 Microsoft is making this Specification available under the Open Web Foundation Final Specification Agreement Version 1.0 ("OWF 1.0") as of October 1, 2012. The OWF 1.0 is available at http://www.openwebfoundation.org/legal/the-owf-1-0-agreements/owfa-1-0. TypeScript is a trademark of Microsoft Corporation. Table of Contents 1 Introduction ................................................................................................................................................................................... 1 1.1 Ambient Declarations ..................................................................................................................................................... 3 1.2 Function Types .................................................................................................................................................................. 3 1.3 Object Types ...................................................................................................................................................................... 4 1.4 Structural Subtyping ....................................................................................................................................................... 6 1.5 Contextual Typing ............................................................................................................................................................ 7 1.6 Classes ................................................................................................................................................................................. -
A System of Constructor Classes: Overloading and Implicit Higher-Order Polymorphism
A system of constructor classes: overloading and implicit higher-order polymorphism Mark P. Jones Yale University, Department of Computer Science, P.O. Box 2158 Yale Station, New Haven, CT 06520-2158. [email protected] Abstract range of other data types, as illustrated by the following examples: This paper describes a flexible type system which combines overloading and higher-order polymorphism in an implicitly data Tree a = Leaf a | Tree a :ˆ: Tree a typed language using a system of constructor classes – a mapTree :: (a → b) → (Tree a → Tree b) natural generalization of type classes in Haskell. mapTree f (Leaf x) = Leaf (f x) We present a wide range of examples which demonstrate mapTree f (l :ˆ: r) = mapTree f l :ˆ: mapTree f r the usefulness of such a system. In particular, we show how data Opt a = Just a | Nothing constructor classes can be used to support the use of monads mapOpt :: (a → b) → (Opt a → Opt b) in a functional language. mapOpt f (Just x) = Just (f x) The underlying type system permits higher-order polymor- mapOpt f Nothing = Nothing phism but retains many of many of the attractive features that have made the use of Hindley/Milner type systems so Each of these functions has a similar type to that of the popular. In particular, there is an effective algorithm which original map and also satisfies the functor laws given above. can be used to calculate principal types without the need for With this in mind, it seems a shame that we have to use explicit type or kind annotations. -
Python Programming
Python Programming Wikibooks.org June 22, 2012 On the 28th of April 2012 the contents of the English as well as German Wikibooks and Wikipedia projects were licensed under Creative Commons Attribution-ShareAlike 3.0 Unported license. An URI to this license is given in the list of figures on page 149. If this document is a derived work from the contents of one of these projects and the content was still licensed by the project under this license at the time of derivation this document has to be licensed under the same, a similar or a compatible license, as stated in section 4b of the license. The list of contributors is included in chapter Contributors on page 143. The licenses GPL, LGPL and GFDL are included in chapter Licenses on page 153, since this book and/or parts of it may or may not be licensed under one or more of these licenses, and thus require inclusion of these licenses. The licenses of the figures are given in the list of figures on page 149. This PDF was generated by the LATEX typesetting software. The LATEX source code is included as an attachment (source.7z.txt) in this PDF file. To extract the source from the PDF file, we recommend the use of http://www.pdflabs.com/tools/pdftk-the-pdf-toolkit/ utility or clicking the paper clip attachment symbol on the lower left of your PDF Viewer, selecting Save Attachment. After extracting it from the PDF file you have to rename it to source.7z. To uncompress the resulting archive we recommend the use of http://www.7-zip.org/. -
Bundled Fragments of First-Order Modal Logic: (Un)Decidability
Bundled Fragments of First-Order Modal Logic: (Un)Decidability Anantha Padmanabha Institute of Mathematical Sciences, HBNI, Chennai, India [email protected] https://orcid.org/0000-0002-4265-5772 R Ramanujam Institute of Mathematical Sciences, HBNI, Chennai, India [email protected] Yanjing Wang Department of Philosophy, Peking University, Beijing, China [email protected] Abstract Quantified modal logic is notorious for being undecidable, with very few known decidable frag- ments such as the monodic ones. For instance, even the two-variable fragment over unary predic- ates is undecidable. In this paper, we study a particular fragment, namely the bundled fragment, where a first-order quantifier is always followed by a modality when occurring in the formula, inspired by the proposal of [15] in the context of non-standard epistemic logics of know-what, know-how, know-why, and so on. As always with quantified modal logics, it makes a significant difference whether the domain stays the same across possible worlds. In particular, we show that the predicate logic with the bundle ∀ alone is undecidable over constant domain interpretations, even with only monadic predicates, whereas having the ∃ bundle instead gives us a decidable logic. On the other hand, over increasing domain interpretations, we get decidability with both ∀ and ∃ bundles with unrestricted predicates, where we obtain tableau based procedures that run in PSPACE. We further show that the ∃ bundle cannot distinguish between constant domain and variable domain interpretations. 2012 ACM Subject Classification Theory of computation → Modal and temporal logics Keywords and phrases First-order modal logic, decidability, bundled fragments Digital Object Identifier 10.4230/LIPIcs.FSTTCS.2018.43 Acknowledgements We thank the reviewers for the insightful and helpful comments. -
Refinement Types for ML
Refinement Types for ML Tim Freeman Frank Pfenning [email protected] [email protected] School of Computer Science School of Computer Science Carnegie Mellon University Carnegie Mellon University Pittsburgh, Pennsylvania 15213-3890 Pittsburgh, Pennsylvania 15213-3890 Abstract tended to the full Standard ML language. To see the opportunity to improve ML’s type system, We describe a refinement of ML’s type system allow- consider the following function which returns the last ing the specification of recursively defined subtypes of cons cell in a list: user-defined datatypes. The resulting system of refine- ment types preserves desirable properties of ML such as datatype α list = nil | cons of α * α list decidability of type inference, while at the same time fun lastcons (last as cons(hd,nil)) = last allowing more errors to be detected at compile-time. | lastcons (cons(hd,tl)) = lastcons tl The type system combines abstract interpretation with We know that this function will be undefined when ideas from the intersection type discipline, but remains called on an empty list, so we would like to obtain a closely tied to ML in that refinement types are given type error at compile-time when lastcons is called with only to programs which are already well-typed in ML. an argument of nil. Using refinement types this can be achieved, thus preventing runtime errors which could be 1 Introduction caught at compile-time. Similarly, we would like to be able to write code such as Standard ML [MTH90] is a practical programming lan- case lastcons y of guage with higher-order functions, polymorphic types, cons(x,nil) => print x and a well-developed module system. -
Lecture Slides
Outline Meta-Classes Guy Wiener Introduction AOP Classes Generation 1 Introduction Meta-Classes in Python Logging 2 Meta-Classes in Python Delegation Meta-Classes vs. Traditional OOP 3 Meta-Classes vs. Traditional OOP Outline Meta-Classes Guy Wiener Introduction AOP Classes Generation 1 Introduction Meta-Classes in Python Logging 2 Meta-Classes in Python Delegation Meta-Classes vs. Traditional OOP 3 Meta-Classes vs. Traditional OOP What is Meta-Programming? Meta-Classes Definition Guy Wiener Meta-Program A program that: Introduction AOP Classes One of its inputs is a program Generation (possibly itself) Meta-Classes in Python Its output is a program Logging Delegation Meta-Classes vs. Traditional OOP Meta-Programs Nowadays Meta-Classes Guy Wiener Introduction AOP Classes Generation Compilers Meta-Classes in Python Code Generators Logging Delegation Model-Driven Development Meta-Classes vs. Traditional Templates OOP Syntactic macros (Lisp-like) Meta-Classes The Problem With Static Programming Meta-Classes Guy Wiener Introduction AOP Classes Generation Meta-Classes How to share features between classes and class hierarchies? in Python Logging Share static attributes Delegation Meta-Classes Force classes to adhere to the same protocol vs. Traditional OOP Share code between similar methods Meta-Classes Meta-Classes Guy Wiener Introduction AOP Classes Definition Generation Meta-Classes in Python Meta-Class A class that creates classes Logging Delegation Objects that are instances of the same class Meta-Classes share the same behavior vs. Traditional OOP Classes that are instances of the same meta-class share the same behavior Meta-Classes Meta-Classes Guy Wiener Introduction AOP Classes Definition Generation Meta-Classes in Python Meta-Class A class that creates classes Logging Delegation Objects that are instances of the same class Meta-Classes share the same behavior vs. -
Soundness of Workflow Nets: Classification
DOI 10.1007/s00165-010-0161-4 The Author(s) © 2010. This article is published with open access at Springerlink.com Formal Aspects Formal Aspects of Computing (2011) 23: 333–363 of Computing Soundness of workflow nets: classification, decidability, and analysis W. M. P. van der Aalst1,2,K.M.vanHee1, A. H. M. ter Hofstede1,2,N.Sidorova1, H. M. W. Verbeek1, M. Voorhoeve1 andM.T.Wynn2 1 Eindhoven University of Technology, P.O. Box 513, 5600 MB Eindhoven, The Netherlands. E-mail: [email protected] 2 Queensland University of Technology, Brisbane, Australia Abstract. Workflow nets, a particular class of Petri nets, have become one of the standard ways to model and analyze workflows. Typically, they are used as an abstraction of the workflow that is used to check the so-called soundness property. This property guarantees the absence of livelocks, deadlocks, and other anomalies that can be detected without domain knowledge. Several authors have proposed alternative notions of soundness and have suggested to use more expressive languages, e.g., models with cancellations or priorities. This paper provides an overview of the different notions of soundness and investigates these in the presence of different extensions of workflow nets. We will show that the eight soundness notions described in the literature are decidable for workflow nets. However, most extensions will make all of these notions undecidable. These new results show the theoretical limits of workflow verification. Moreover, we discuss some of the analysis approaches described in the literature. Keywords: Petri nets, Decidability, Workflow nets, Reset nets, Soundness, Verification 1. -
Undecidable Problems: a Sampler
UNDECIDABLE PROBLEMS: A SAMPLER BJORN POONEN Abstract. After discussing two senses in which the notion of undecidability is used, we present a survey of undecidable decision problems arising in various branches of mathemat- ics. 1. Introduction The goal of this survey article is to demonstrate that undecidable decision problems arise naturally in many branches of mathematics. The criterion for selection of a problem in this survey is simply that the author finds it entertaining! We do not pretend that our list of undecidable problems is complete in any sense. And some of the problems we consider turn out to be decidable or to have unknown decidability status. For another survey of undecidable problems, see [Dav77]. 2. Two notions of undecidability There are two common settings in which one speaks of undecidability: 1. Independence from axioms: A single statement is called undecidable if neither it nor its negation can be deduced using the rules of logic from the set of axioms being used. (Example: The continuum hypothesis, that there is no cardinal number @0 strictly between @0 and 2 , is undecidable in the ZFC axiom system, assuming that ZFC itself is consistent [G¨od40,Coh63, Coh64].) The first examples of statements independent of a \natural" axiom system were constructed by K. G¨odel[G¨od31]. 2. Decision problem: A family of problems with YES/NO answers is called unde- cidable if there is no algorithm that terminates with the correct answer for every problem in the family. (Example: Hilbert's tenth problem, to decide whether a mul- tivariable polynomial equation with integer coefficients has a solution in integers, is undecidable [Mat70].) Remark 2.1. -
The ∀∃ Theory of D(≤,∨, ) Is Undecidable
The ∀∃ theory of D(≤, ∨,0 ) is undecidable Richard A. Shore∗ Theodore A. Slaman† Department of Mathematics Department of Mathematics Cornell University University of California, Berkeley Ithaca NY 14853 Berkeley CA 94720 May 16, 2005 Abstract We prove that the two quantifier theory of the Turing degrees with order, join and jump is undecidable. 1 Introduction Our interest here is in the structure D of all the Turing degrees but much of the motivation and setting is shared by work on other degree structures as well. In particular, Miller, Nies and Shore [2004] provides an undecidability result for the r.e. degrees R at the two quantifier level with added function symbols as we do here for D. To set the stage, we begin then with an adaptation of the introduction from that paper including statements of some of its results and so discuss R, the r.e. degrees and D(≤ 00), the degrees below 00 as well. A major theme in the study of degree structures of all types has been the question of the decidability or undecidability of their theories. This is a natural and fundamental question that is an important goal in the analysis of these structures. It also serves as a guide and organizational principle for the development of construction techniques and algebraic information about the structures. A decision procedure implies (and requires) a full understanding and control of the first order properties of a structure. Undecidability results typically require and imply some measure of complexity and coding in the struc- ture. Once a structure has been proven undecidable, it is natural to try to determine both the extent and source of the complexity. -
Marshmallow-Annotations Documentation Release 2.4.1
marshmallow-annotations Documentation Release 2.4.1 Alec Nikolas Reiter Jan 28, 2021 Contents 1 Installation 3 2 Content 5 Index 21 i ii marshmallow-annotations Documentation, Release 2.4.1 Version 2.4.1 (Change Log) marshmallow-annotations allows you to create marshmallow schema from classes with annotations on them: # music.py from typing import List class Album: id: int name: str def __init__(self, id: int, name: str): self.id= id self.name= name class Artist: id: int name: str albums: List[Album] def __init__(self, id: int, name: str, albums: List[Album]): self.id= id self.name= name self.albums= albums # schema.py from marshmallow_annotations import AnnotationSchema from.music import Album, Artist class AlbumScheme(AnnotationSchema): class Meta: target= Album register_as_scheme= True class ArtistScheme(AnnotationSchema): class Meta: target= Artist register_as_scheme= True scheme= ArtistScheme() scheme.dump( Artist( id=1, name="Abominable Putridity", albums=[ Album( id=1, name="The Anomalies of Artificial Origin" ) ] ) ) #{ # "albums": [ #{ # "id": 1, (continues on next page) Contents 1 marshmallow-annotations Documentation, Release 2.4.1 (continued from previous page) # "name": "The Anomalies of Artificial Origin" #} # ], # "id": 1, # "name": "Abominable Putridity" #} 2 Contents CHAPTER 1 Installation marshmallow-annotations is available on pypi and installable with: pip install marshmallow-annotations marshmallow-annotations supports Python 3.6+ and marshmallow 2.x.x Note: If you are install marshmallow-annotations outside of a virtual environment, consider installing with pip install --user marshmallow-annotations rather than using sudo or adminstrator privileges to avoid installing it into your system Python. 3 marshmallow-annotations Documentation, Release 2.4.1 4 Chapter 1. Installation CHAPTER 2 Content 2.1 Quickstart This guide will walk you through the basics of using marshmallow-annotations.