type-theory | 易学教程

What exactly is a Set in COQ

阅读更多关于 What exactly is a Set in COQ

问题 I'm still puzzled what the sort Set means in COQ. When do I use Set and when do I use Type ? In Hott a Set is defined as a type, where identity proofs are unique. But I think in Coq it has a different interpretation. 回答1: Set means rather different things in Coq and HoTT. In Coq, every object has a type, including types themselves. Types of types are usually referred to as sorts , kinds or universes . In Coq, the (computationally relevant) universes are Set , and Type_i , where i ranges over

What is the analog of Category in programming

阅读更多关于 What is the analog of Category in programming

问题 I found that there is an isomorphism between logic and programming, called Curry-Howard correspondence, so is there any such equivalence for Category theory, which helps to understand things like Functors or Monads? 回答1: Yes! It's called Curry–Howard–Lambek - it maps Category objects to types and morphisms to terms. So, typed lambda (function without name) or even function may be represented as cartesian-closed category, where Unite-type becomes a terminal object, set of types (or more

Why do We Need Sum Types?

阅读更多关于 Why do We Need Sum Types?

问题 Imagine a language which doesn't allow multiple value constructors for a data type. Instead of writing data Color = White | Black | Blue we would have data White = White data Black = Black data Blue = Black type Color = White :|: Black :|: Blue where :|: (here it's not | to avoid confusion with sum types) is a built-in type union operator. Pattern matching would work in the same way show :: Color -> String show White = "white" show Black = "black" show Blue = "blue" As you can see, in

Pattern matching in Observational Type Theory

阅读更多关于 Pattern matching in Observational Type Theory

In the end of the "5. Full OTT" section of Towards Observational Type Theory the authors show how to define coercible-under-constructors indexed data types in OTT. The idea is basically to turn indexed data types into parameterized like this: data IFin : ℕ -> Set where zero : ∀ {n} -> IFin (suc n) suc : ∀ {n} -> IFin n -> IFin (suc n) data PFin (m : ℕ) : Set where zero : ∀ {n} -> suc n ≡ m -> PFin m suc : ∀ {n} -> suc n ≡ m -> PFin n -> PFin m Conor also mentions this technique at the bottom of observational type theory (delivery) : The fix, of course, is to do what the GADT people did, and

Are there type signatures which Haskell can't verify?

阅读更多关于 Are there type signatures which Haskell can't verify?

问题 This paper establishes that type inference (called "typability" in the paper) in System F is undecidable. What I've never heard mentioned elsewhere is the second result of the paper, namely that "type checking" in F is also undecidable. Here the "type checking" question means: given a term t , type T and typing environment A , is the judgment A ⊢ t : T derivable? That this question is undecidable (and that it's equivalent to the question of typability) is surprising to me, because it seems

How to make these dynamically typed functions type-safe? [closed]

阅读更多关于 How to make these dynamically typed functions type-safe? [closed]

Closed . This question needs to be more focused. It is not currently accepting answers. Learn more . Want to improve this question? Update the question so it focuses on one problem only by editing this post . Is there any programming language (or type system) in which you could express the following Python-functions in a statically typed and type-safe way (without having to use casts, runtime-checks etc)? #1 : # My function - What would its type be? def Apply(x): return x(x) # Example usage print Apply(lambda _: 42) #2 : white = None black = None def White(): for x in xrange(1, 10): print (

Why do We Need Sum Types?

阅读更多关于 Why do We Need Sum Types?

Imagine a language which doesn't allow multiple value constructors for a data type. Instead of writing data Color = White | Black | Blue we would have data White = White data Black = Black data Blue = Black type Color = White :|: Black :|: Blue where :|: (here it's not | to avoid confusion with sum types) is a built-in type union operator. Pattern matching would work in the same way show :: Color -> String show White = "white" show Black = "black" show Blue = "blue" As you can see, in contrast to coproducts it results in a flat structure so you don't have to deal with injections. And, unlike

Dependent types can prove your code is correct up to a specification. But how do you prove the specification is correct?

阅读更多关于 Dependent types can prove your code is correct up to a specification. But how do you prove the specification is correct?

问题 Dependent types are often advertised as a way to enable you to assert that a program is correct up to a specification. So, for example, you are asked to write a code that sorts a list - you are able to prove that code is correct by encoding the notion of "sort" as a type, and writing a function such as List a -> SortedList a . But how do you prove that the specification, SortedList , is correct? Wouldn't it be the case that, the more complex your specification is, the more likely it would be

Are there type signatures which Haskell can't verify?

阅读更多关于 Are there type signatures which Haskell can't verify?

This paper establishes that type inference (called "typability" in the paper) in System F is undecidable. What I've never heard mentioned elsewhere is the second result of the paper, namely that "type checking" in F is also undecidable. Here the "type checking" question means: given a term t , type T and typing environment A , is the judgment A ⊢ t : T derivable? That this question is undecidable (and that it's equivalent to the question of typability) is surprising to me, because it seems intuitively like it should be an easier question to answer. But in any case, given that Haskell is based

Why do we need containers?

阅读更多关于 Why do we need containers?

(As an excuse: the title mimics the title of Why do we need monads? ) There are containers (and indexed ones) (and hasochistic ones) and descriptions . But containers are problematic and to my very small experience it's harder to think in terms of containers than in terms of descriptions. The type of non-indexed containers is isomorphic to Σ — that's quite too unspecific. The shapes-and-positions description helps, but in ⟦_⟧ᶜ : ∀ {α β γ} -> Container α β -> Set γ -> Set (α ⊔ β ⊔ γ) ⟦ Sh ◃ Pos ⟧ᶜ A = ∃ λ sh -> Pos sh -> A Kᶜ : ∀ {α β} -> Set α -> Container α β Kᶜ A = A ◃ const (Lift ⊥) we are