I'm developing a code with a lot of boring list concatenation equalities, so I do want to use a monoid solver. I know that module Algebra.Monoid-solver implements a monoid solver, but I do not find any example on how to use it.
Can someone provide a quick example using the stdlib monoid solver ?
Best,
Here is a quick example:
open import Relation.Binary.PropositionalEquality
open import Data.List
open import Data.List.Properties
open List-solver renaming (nil to :[]; _⊕_ to _:++_; _⊜_ to _:≡_)
assoc : {A : Set} (xs ys zs : List A) -> xs ++ (ys ++ zs) ≡ (xs ++ ys) ++ zs
assoc = solve 3 (λ xs ys zs -> xs :++ (ys :++ zs) :≡ (xs :++ ys) :++ zs) refl
Agda can partially infer the type signature:
assoc : {A : Set} (xs ys zs : List A) -> _
assoc = solve 3 (λ xs ys zs -> xs :++ (ys :++ zs) :≡ (xs :++ ys) :++ zs) refl
There are also at least two front-ends for the ring solver: 1 and 2, you can write a front-end for the monoid solver in a similar way.
Have you considered using difference lists, which have definitional associativity?
Check this thread also.
Related
I'm playing around with the type of finite multisets as defined in the cubical standard library here:
https://github.com/agda/cubical/blob/0d272ccbf6f3b142d1b723cead28209444bc896f/Cubical/HITs/FiniteMultiset/Base.agda#L15
data FMSet (A : Type ℓ) : Type ℓ where
[] : FMSet A
_∷_ : (x : A) → (xs : FMSet A) → FMSet A
comm : ∀ x y xs → x ∷ y ∷ xs ≡ y ∷ x ∷ xs
trunc : isSet (FMSet A)
I was able to reproduce the proofs for count extensionality and one of my lemmas I showed that you can remove a element from both sides of an equality and keep the equality.
It was similar to this one: https://github.com/agda/cubical/blob/0d272ccbf6f3b142d1b723cead28209444bc896f/Cubical/HITs/FiniteMultiset/Properties.agda#L183
remove1-≡-lemma : ∀ {a} {x} xs → a ≡ x → xs ≡ remove1 a (x ∷ xs)
remove1-≡-lemma {a} {x} xs a≡x with discA a x
... | yes _ = refl
... | no a≢x = ⊥.rec (a≢x a≡x)
My proofs weren't using the same syntax but in the core libraries syntax it was
cons-path-lemma : ∀ {x} xs ys → (x ∷ xs) ≡ (x ∷ ys) → xs ≡ ys
where the proof is using remove1-≡-lemma path composed on both side of a path which is the argument path functionally composed with remove1 x.
This requires the type of the values to have decidable equality as remove1 doesn't make sense without it. But the lemma itself doesn't mention decidable equality, and so I thought I would try to prove it without having that as a hypothesis. Its now a week later and I'm at my wits end because this seems so 'obvious' but so stubborn to prove.
I'm thinking that my intuition about this being provable may be coming from my classical math background, and so it doesn't follow constructively/contiuously.
So my question is: Is this provable with no assumptions on the element type? If so what would the general structure of the proof look like, I have had trouble getting proofs that want to induct over the two FMSets simultaneously to work (as I'm mostly guessing when trying to get paths to line up as necessary). If it is not provable with no assumptions, is it possible to show that it is equivalent in some form to the necessary assumptions?
I can't offer a proof but an argument why it should be provable without assuming decidability. I think finite multisets can be represented as functions Fin n -> A and equality between multisets f and g is given by a permutation phi : Fin n ~ Fin n, (that is invertible functions on Fin n) such that f o phi = g. Now
(a :: f) 0 = a
(a :: f) (suc i) = f i
If phi : Fin (suc n) ~ Fin (suc n) proves that a :: f = a :: g you can construct a psi : Fin n ~ Fin n which proves that f = g. If phi 0 = 0 then psi n = phi (suc n) otherwise you have to obtain psi by assigning phi^-1 0 to phi 0. However this case analysis is on Fin n.
I think representing the permutation group by swapping adjacent elements is just an inconvenient representation for this problem.
In Agda, it seems it is not possible to show ∀ {A : Set} (f : ⊥ → A) → f ≡ λ ().
However, the seemingly similar term ∀ {A : Set} (f : ⊤ → A) → f ≡ λ _ → f tt can be proven by refl. It can be later used to prove a form of extensionality for ⊤:
ext⊤ : ∀ {A : Set} (f g : ⊤ → A) (H : ∀ x → f x ≡ g x) → f ≡ g
According to this question and answer, the explanation might be in considering different models of type theory. Is it possible to have any intuition on why one is accepted and not the other? Shouldn't f ≡ λ () be some form of eta law?
The ⊤ type has the eta rule which says that any terms with that type are definitionally equal. Hence, f ≡ (λ x → f x) ≡ (λ x → f tt).
⊥ does not have an eta rule in Agda. If f : ⊥ → A, then we only know that f ≡ λ x → f x. λ () is essentially syntactic sugar for ⊥-elim, and f is not definitionally equal to ⊥-elim.
I draw your attention that the first statement is attempting to prove the uniqueness of ⊥ → A. Usually it is true up to isomorphism.
The full correspondence would have been between ∀ {A : Set} (f : ⊤ → A) → f ≡ λ _ → f tt and ∀ {A : Set} (f : ⊥ → A) → f ≡ λ _ → f () - the expression for ⊤ constructs the value tt, so you should be constructing a value for ⊥.
Agda has no means of constructing a value of ⊥, so () is not a valid constructor, it is only a placeholder for what you want.
Although it isn't really pattern-matching, it probably is not harmful to see the use of () as pattern-matching for the empty type - it is allowed to occur only in the pattern-matching positions.
This is intended to show the similarity is superficial, so should amend your intuition about the expressions.
Shouldn't f ≡ λ () be some form of eta law?
It is not clear what you would gain from that. Many things can be proven only up to isomorphism. So, for example, proving the uniqueness of ⊥ → A could correspond to proving the uniqueness of A → ⊤ (not eta-equality of f and λ _ → f tt). Both of these is doable.
I noticed that the Cubical standard library defines Fin as a dependent pair instead of an indexed inductive type. The reason why is that Cubical Agda does not fully support indexed inductive types: https://github.com/agda/cubical/pull/104#discussion_r268476220
A linked issue states that pattern matching doesn't work on inductive families because hcomp and transp haven't been defined on them: https://github.com/agda/cubical/pull/57#issuecomment-461174095
I defined Fin and Vec and wrote a pattern-matching function, and it seems to work fine:
{-# OPTIONS --cubical --safe #-}
open import Cubical.Foundations.Prelude
open import Cubical.Data.Nat using (ℕ; zero; suc)
private
variable
ℓ : Level
A : Type ℓ
n : ℕ
data Fin : ℕ → Type₀ where
fzero : Fin (suc n)
fsuc : Fin n → Fin (suc n)
data Vec (A : Type ℓ) : ℕ → Type ℓ where
[] : Vec A zero
_∷_ : A → Vec A n → Vec A (suc n)
_[_] : Vec A n → Fin n → A
(x ∷ _) [ fzero ] = x
(_ ∷ xs) [ fsuc n ] = xs [ n ]
p : (1 ∷ (2 ∷ [])) [ fzero ] ≡ 1
p = refl
Yet this issue is still open: https://github.com/agda/agda/issues/3733
I want to use Cubical Agda just in case I need higher inductive types or function extensionality, but I don't want to give up Vec or the indexed definition of Fin. I am unfamiliar with the details of Cubical Type Theory, so I don't know where hcomp and transp would be invoked. What is the current status of inductive families in Cubical Agda? Can I still use them if I avoid certain operations?
It is fine to use inductive families with cubical agda, and pattern matching definitions work in the sense that they do compute for the declared constructors of the family.
The limitation that will be addressed by https://github.com/agda/agda/issues/3733 is the following:
A term like subst Fin refl fzero will not compute to fzero or any other constructor, which also means that
(x ∷ _) [ subst Fin refl fzero ]
will not compute to x either.
We can still prove subst Fin refl fzero ≡ fzero by substRefl from the library, so we can also prove (x ∷ _) [ subst Fin refl fzero ] ≡ x.
So currently it is a choice between using inductive families and dealing with subst and transport getting stuck on them, or otherwise encoding everything with paths and lose the nice pattern matching.
I know that there is an AVL tree in the standard library, but that feels too complex for my purposes. A vanilla function meets most my requirements, except for being able to iterate over the keys.
It is not like I strictly do not know how to make some proposition that for every element in a list there is no duplicate - I did so in Coq once, but I am trying to get a handle on how to bake it into the structure directly and am running into difficulties.
open import Relation.Nullary
open import Relation.Binary.PropositionalEquality
data UniqueList {a} (A : Set a) : Set a
data NotIn {a} {A : Set a} : A → UniqueList A → Set a
data UniqueList A where
[] : UniqueList A
_∷_ : ∀ (x : A) (xs : UniqueList A) → NotIn x xs → UniqueList A
data NotIn {a} {A} where
done : ∀ (x : A) → NotIn x []
dive : ∀ (x y : A) (ys : UniqueList A) (prf : NotIn y ys) → NotIn x ys → ¬ x ≡ y → NotIn x ((y ∷ ys) prf)
I thought I might try something like this, but it feels awkward. Any advice for how to deal with this?
#### Exercise `Any-∃`
Show that `Any P xs` is isomorphic to `∃[ x ∈ xs ] P x`.
Leaving aside the fact that ∃[ x ∈ xs ] P x is not even valid syntax - only Σ[ x ∈ xs ] P x could be valid, none of the type signatures I've tried typecheck for that particular problem.
Any-∃ : ∀ {A : Set} {P : A → Set} {xs : List A} → Any P xs ≃ Σ[ x ∈ xs ] P x
List A !=< Set _a_1582 of type Set
when checking that the expression xs has type Set _a_1582
The most obvious thing here fails. I sort of understand what the question is trying to ask me here, but I am not sure what the structure ∃[ x ∈ xs ] P x is supposed to be.
This is the penultimate exercise in the Lists chapter of the PLFA book.
The book has been corrected now:
Exercise Any-∃ (practice)
Show that Any P xs is isomorphic to ∃[ x ] (x ∈ xs × P x).