This is from the 2019 Cubical Agda intro paper.
They are not in Cubical.Core.Everything and even file content search for the Cubical v0.1 library is not turning up anything for me.
{-# OPTIONS --cubical #-}
open import Cubical.Core.Everything
open import Data.Nat
data Pos : Set where
pos1 : Pos
x0 : Pos → Pos
x1 : Pos → Pos
data Bin : Set where
bin0 : Bin
binPos : Pos → Bin
ℕ≃Bin : ℕ ≃ Bin
ℕ≃Bin = isoToEquiv (iso ℕ→Bin Bin→ℕ Bin→ℕ→Bin ℕ→Bin→ℕ)
I am trying to get this short fragment near the start to run.
You can find those in Cubical.Foundations.Isomorphism and Cubical.Foundations.Equiv
Related
I can trivially prove that not equals is irrelevant with function extensionality:
open import Relation.Binary.PropositionalEquality using (_≢_)
open import Relation.Binary using (Irrelevant)
open import Relation.Nullary.Negation using (contradiction)
open import Axiom.Extensionality.Propositional using (Extensionality)
postulate
fun-ext : ∀ {ℓ₁ ℓ₂} → Extensionality ℓ₁ ℓ₂
≢-irrelevant : ∀ {a} {A : Set a} → Irrelevant {A = A} _≢_
≢-irrelevant {x} {y} [x≉y]₁ [x≉y]₂ = fun-ext (λ x≈y → contradiction x≈y [x≉y]₁)
This seems impossible to prove without funext when A is polymorphic but is it possible when A = ℕ or A = Bool?
This is not provable without funext. We did consider changing the definition of the empty type to make these provable however it was deemed too invasive a change.
I am not confident enough to try proving properties about the AVL tree that is there, so I want to try something simpler. I could implement it on my own, but do not want to spend time doing that if it is already hiding in the library somewhere.
You could use a list of pairs and the notion of membership can then be encoded via Any.
Bits of a very basic library:
open import Data.List.Base using (List)
open import Data.List.Relation.Unary.Any
open import Data.Maybe
open import Data.Product
open import Function
open import Relation.Binary
open import Relation.Binary.PropositionalEquality
open import Relation.Nullary
AssocList : Set → Set → Set
AssocList A B = List (A × B)
private
variable
A B : Set
_∈_ : A → AssocList A B → Set
a ∈ abs = Any ((a ≡_) ∘ proj₁) abs
module Decidable {A : Set} (_≟_ : Decidable {A = A} _≡_) where
_∈?_ : Decidable (_∈_ {A} {B})
a ∈? abs = any ((a ≟_) ∘ proj₁) abs
_‼_ : (abs : AssocList A B) (a : A) → Maybe B
abs ‼ a with a ∈? abs
... | yes p = just (proj₂ (lookup p))
... | no ¬p = nothing
open import Data.Vec
open import Data.Nat
open import Data.Fin
open import Data.Integer
open import Data.Rational
open import Data.Product
open import Relation.Binary.PropositionalEquality using (_≡_; refl)
Infoset = ℕ
Size = ℕ
Player = ℤ
data GameTree (infoset-size : Infoset → Size) : Set where
Terminal : (reward : ℚ) → GameTree infoset-size
Response : (id : Infoset) → (subnodes : Vec (GameTree infoset-size) (infoset-size id)) → GameTree infoset-size
record Policy (infoset-size : Infoset → Size) : Set where
field
σ : ∀ (id : Infoset) → Vec ℚ (infoset-size id)
wf-elem : ∀ (id : Infoset) (i : Fin (infoset-size id)) → 0ℚ Data.Rational.≤ lookup (σ id) i × lookup (σ id) i Data.Rational.≤ 1ℚ
Had I written the above like 0ℚ ≤ lookup (σ id) i × lookup (σ id) i ≤ 1ℚ I would have gotten the following type error.
Ambiguous name _≤_. It could refer to any one of
Data.Nat._≤_ bound at
C:\Users\Marko\AppData\Roaming\cabal\x86_64-windows-ghc-8.6.5\Agda-2.6.0\lib\agda-stdlib\src\Data\Nat\Base.agda:33,6-9
Data.Fin._≤_ bound at
C:\Users\Marko\AppData\Roaming\cabal\x86_64-windows-ghc-8.6.5\Agda-2.6.0\lib\agda-stdlib\src\Data\Fin\Base.agda:218,1-4
Data.Integer._≤_ bound at
C:\Users\Marko\AppData\Roaming\cabal\x86_64-windows-ghc-8.6.5\Agda-2.6.0\lib\agda-stdlib\src\Data\Integer\Base.agda:44,6-9
Data.Rational._≤_ bound at
C:\Users\Marko\AppData\Roaming\cabal\x86_64-windows-ghc-8.6.5\Agda-2.6.0\lib\agda-stdlib\src\Data\Rational\Base.agda:71,6-9
Is there some elegant way to induce to make Agda infer the right functions to use on its own? Here it should be capable of doing the right thing given that the types are known.
Agda allows ambiguous constructors and ambiguous projections, but any other names have to be unambigous at the position where they are used.
To avoid ambiguity, you can rename a symbol using the open import Data.Nat renaming (_≤_ to _≤Nat_) syntax. Alternatively, you can use open import Data.Nat as Nat and use x Nat.≤ y.
A different library design could make use of instance arguments to provide ad-hoc overloading (for example the Agda prelude).
The following code is meant to describe C/C++-like enumerations which can take 4 bytes although all they are supposed to contain is just a few different alternatives.
open import Prelude.Bool
open import Prelude.Nat
open import Agda.Builtin.Nat
open import Agda.Builtin.Equality
open import Numeric.Nat.Pow renaming (_^′_ to _^_)
data Enum : Set where
makeEnum : (size : Nat) → (variants : Nat) →
.{{ _ : (variants < size) ≡ true }} → Enum
five : Enum
five = makeEnum (2 ^ 32) 5
data Expr : (t : Enum) → Set where
constant : (x : Nat) → Expr five
So far so good. Everything type checks nicely. However adding the following lines
func : ∀ {t} → Expr t → Bool
func (constant x) = false
that don't appear to be doing much of anything, leads to a nontermination of the type checker and depletion of all system resources.
I don't see anything besides the instance argument that could lead to this, but that does not seem to agree with the fact that Agda is able to both solve and type check the following
5<2³² : (5 < 2 ^ 32) ≡ true
5<2³² = refl
in no time. So what is going on?
The question was answered by Jesper Cockx. As it turns out it was a compiler bug that will be fixed in the next version of Agda.
Update: the bug has already been fixed in the master branch.
I'm proving stuff in Agda, and some of my files are starting to get a bit long and cluttered (even after I refactored into smaller modules). Is it possible to have two files, one of which contains type signatures of theorems only, and another which contains those theorems and proofs? I looked at the abstract keyword, but that doesn't quite seem to do the right thing.
Of course, I can put all the type signatures at the top of the file, and have all the proofs at the bottom of the file; but it seems cleaner if I could have the statements in a file to themselves.
You could give names to the types of your lemmas. E.g. in file Statement.agda:
module Statement where
open import Agda.Builtin.Nat
open import Agda.Builtin.Equality
+-sym : Set
+-sym = ∀ m n → m + n ≡ n + m
And in file Proof.agda:
module Proof where
open import Agda.Builtin.Nat
open import Agda.Builtin.Equality
import Statement
+-sym : Statement.+-sym
+-sym m n = {!!}
In case your definition is level-polymorphic, Agda unfortunately doesn't have a (surface) name for types of the form ∀ {ℓ : Level} → .... You will have to take the levels as arguments in Statement and quantify over them universally when using the statement in Proof. This would give you something like this:
In Statement.agda:
open import Agda.Primitive
data ⊥ : Set where
⊥-elim : (ℓ : Level) → Set (lsuc ℓ)
⊥-elim ℓ = ∀ {A : Set ℓ} → ⊥ → A
In Proof.agda:
⊥-elim : ∀ {ℓ} → Statement.⊥-elim ℓ
⊥-elim = {!!}