Assume there are four types , D, Q, P, C
data Q : Set where
q1 : Q
q2 : Q
data P : Set where
p1 : P
p2 : P
data C : Set where
c1 : C
c2 : C
data D : Set where
d1 : D
d2 : D
When trying to define function
f : Set -> Set
f D = Q
f P = C
I get the warning unreachable clause .
I assume it is because domains of Agda function are defined on sets but not category of sets.
What if I want a mapping relation which behaves like a close type family in Haskell ?
Because the Agda compiler erases types during compilation, it is not allowed to pattern match on Set directly. (The error 'unreachable clause' is a bit confusing but it results from Agda interpreting D as a pattern variable rather than the datatype.)
The usual way to work around this problem is to define your own universe, i.e. a datatype whose elements are interpreted as specific sets. Here is an example:
data Q : Set where
q1 : Q
q2 : Q
data P : Set where
p1 : P
p2 : P
data C : Set where
c1 : C
c2 : C
data D : Set where
d1 : D
d2 : D
-- Our little universe
data U : Set where
d : U
p : U
-- The interpretation function
⟦_⟧ : U → Set
⟦ d ⟧ = D
⟦ p ⟧ = P
f : U → Set
f d = Q
f p = C
-- An example of how to use f:
omo : {u : U} → ⟦ u ⟧ → f u
omo {d} d1 = q1
omo {d} d2 = q2
omo {p} p1 = c1
omo {p} p2 = c2
Related
I was asked to finish one of the recommended question from plfa:
Exercise ⇔≃× (recommended)
Show that A ⇔ B as defined earlier is isomorphic to (A → B) × (B → A).
I know I need to prove some property of equivalence first, and here is my proof:
record _⇔_ (A B : Set) : Set where
field
to : A → B
from : B → A
⇔-refl : ∀ {A : Set} → A ⇔ A
⇔-refl =
record
{ to = λ{x → x}
; from = λ{y → y}
}
⇔-sym : ∀ {A B : Set}
→ A ⇔ B
→ B ⇔ A
⇔-sym A⇔B =
record
{ to = _⇔_.from A⇔B
; from = _⇔_.to A⇔B
}
⇔-trans : ∀ {A B C : Set}
→ A ⇔ B
→ B ⇔ C
→ A ⇔ C
⇔-trans A⇔B B⇔C =
record
{ to = (_⇔_.to B⇔C) ∘ (_⇔_.to A⇔B )
; from = (_⇔_.from A⇔B) ∘ (_⇔_.from B⇔C )
}
And now, from my understanding, I need to prove
⇔≃× : ∀ {A B : Set} → A ⇔ B ≃ (A → B) × (B → A)
So to prove this, we need to prove four sections: "to" "from" "from∘to" "to∘from"
⇔≃× : ∀ {A B : Set} → (A ⇔ B) ≃ ((A → B) × (B → A))
⇔≃× =
record
{ to = λ{ x ⇔ y → ⟨ ( x → y ) , ( y → x ) ⟩ }
; from = ?
; from∘to = ?
; to∘from = ?
}
But when I finish the "to" section, I want to see if it can pass. So I compile and I got this error message:
Cannot eliminate type (A → B) × (B → A) with variable pattern ⇔(did you supply too many arguments?)when checking the clause left hand side.extendedlambda2 x ⇔ y
Can anyone give some explanation on this type of error message?
Thanks in advance
λ{ x ⇔ y → binds three arguments: x, ⇔, and y but the function you're supposed to define only takes one.
I have a function like this:
open import Data.Char
open import Data.Nat
open import Data.Bool
open import Relation.Binary.PropositionalEquality
open Relation.Binary.PropositionalEquality.≡-Reasoning
foo : Char → Char → ℕ
foo c1 c2 with c1 == c2
... | true = 123
... | false = 456
I would like to prove that when I call it with the same argument (foo c c), it always yields 123:
foo-eq⇒123 : ∀ (c : Char) → foo c c ≡ 123
foo-eq⇒123 c =
foo c c ≡⟨ {!!} ⟩
123 ∎
I am able to use refl to prove a trivial example:
foo-example : foo 'a' 'a' ≡ 123
foo-example = refl
So, I would think that I could just put refl in the hole since all Agda needs to do is beta-reduce foo c c. However, replacing the hole with refl yields the following error:
.../Unfold.agda:15,14-18
(foo c c
| Relation.Nullary.Decidable.Core.isYes
(Relation.Nullary.Decidable.Core.map′ Data.Char.Properties.≈⇒≡
Data.Char.Properties.≈-reflexive
(Relation.Nullary.Decidable.Core.map′
(Data.Nat.Properties.≡ᵇ⇒≡ (toℕ c) (toℕ c))
(Data.Nat.Properties.≡⇒≡ᵇ (toℕ c) (toℕ c)) (T? (toℕ c ≡ᵇ toℕ c)))))
!= 123 of type ℕ
when checking that the expression refl has type foo c c ≡ 123
I suspect the issue is that Agda doesn't automatically understand that c == c is true for all c:
c==c : ∀ (c : Char) → (c == c) ≡ true
c==c c = refl
.../Unfold.agda:23,10-14
Relation.Nullary.Decidable.Core.isYes
(Relation.Nullary.Decidable.Core.map′ Data.Char.Properties.≈⇒≡
Data.Char.Properties.≈-reflexive
(Relation.Nullary.Decidable.Core.map′
(Data.Nat.Properties.≡ᵇ⇒≡ (toℕ c) (toℕ c))
(Data.Nat.Properties.≡⇒≡ᵇ (toℕ c) (toℕ c)) (T? (toℕ c ≡ᵇ toℕ c))))
!= true of type Bool
when checking that the expression refl has type (c == c) ≡ true
So, what is the right way to prove my foo-eq⇒123 theorem?
Agda's built-in Char type is a little weird. Let's contrast it with a non-weird built-in type, ℕ. The equality test for ℕ looks as follows.
_≡ᵇ_ : Nat → Nat → Bool
zero ≡ᵇ zero = true
suc n ≡ᵇ suc m = n ≡ᵇ m
_ ≡ᵇ _ = false
Note that n ≡ᵇ n doesn't reduce to true, either. After all, Agda doesn't know whether n is zero or suc, i.e., which of the two clauses to apply for the reduction. So, this has the same problem as your Char example. But for ℕ there is an easy way out.
Let's look at your example again and let's also add a ℕ-based version of foo, bar.
open import Data.Char using (Char ; _==_ ; _≟_)
open import Data.Nat using (ℕ ; zero ; suc ; _≡ᵇ_)
open import Data.Bool using (true ; false)
open import Relation.Binary.PropositionalEquality using (_≡_ ; refl)
open import Relation.Nullary using (yes ; no)
open import Relation.Nullary.Negation using (contradiction)
foo : Char → Char → ℕ
foo c1 c2 with c1 == c2
... | true = 123
... | false = 456
bar : ℕ → ℕ → ℕ
bar n1 n2 with n1 ≡ᵇ n2
... | true = 123
... | false = 456
So, what's the easy way out for ℕ? We pattern match / do a case split on n to reduce n ≡ᵇ n just enough to do our proof. I.e., either to the base case zero or to the next recursive step suc n.
bar-eq⇒123 : ∀ n → bar n n ≡ 123
bar-eq⇒123 zero = refl
bar-eq⇒123 (suc n) = bar-eq⇒123 n
ℕ just has two constructors and we know what ≡ᵇ looks like, so pattern matching is straight forward.
For Char, things are way more complicated. Long story short, the equality test for Char is defined in terms of a function toℕ that Agda doesn't give us a definition for. Also, the Char data type is postulated and doesn't come with any constructors. So a proof like bar-eq⇒123 is not an option for Char. We don't have clauses and we don't have constructors. (I wouldn't call, say, 'a' a constructor for Char. Similarly to how 1234 is not a constructor for ℕ.)
So, what could we do? Note that c == c in the error message that you quoted reduces to something pretty complicated that involves isYes. If we reduced c == c only a tiny little bit (instead of as much as possible), we'd get isYes (c ≟ c) (instead of the complicated thing from the error message).
_≟_ is the decidable equality for Char (i.e., a combination of an "Equal or not?" Boolean and a proof). isYes strips away the proof and gives us the Boolean.
My idea for a proof would then be to not do a case split on c (as we did for ℕ), but on c ≟ c. This would yield two cases and reduce the isYes to true or false, respectively. The true case would be obvious. The false case could be dicharged by contradiction with the proof from the decidable equality.
foo-eq⇒123 : ∀ c → foo c c ≡ 123
foo-eq⇒123 c with c ≟ c
... | yes p = refl
... | no ¬p = contradiction refl ¬p
Note that, in turn, this proof doesn't easily translate to ℕ, as _≡ᵇ_ isn't based on decidable equality and isYes. It's a primitive instead.
Maybe an even better idea would be to consistently stick to decidable equality, for Char as well as ℕ instead of using _==_ or _≡ᵇ_. foo would then look as follows.
baz : Char → Char → ℕ
baz c1 c2 with c1 ≟ c2
... | yes p = 123
... | no ¬p = 456
And the foo-eq⇒123 proof would apply to it unchanged.
I'm getting a strange error of the form x != y of type Y when checking that the pattern p(y) has type Z. I do not know why or how I'm getting this and would like to solve the issue. A problem instance follows; thank-you.
Suppose I've a set,
postulate A : Set
and a way to interpret its elements as sets,
postulate F : A → Set
Then using pairs of that set,
record B : Set where field s t : A
I can build a parametrised type on it:
data C : A → Set where MkC : (b : B) → F (B.s b) → C (B.t b)
Now I'd like to, for example, form a function
ABCF : ∀ a → (f : A → A) → C a → C (f a)
ABCF t f e = {!!}
and I'd do so by pattern matching on the third argument via C-c C-c
and doing so gets me
ABCF .(B.t b) f (MkC b x) = {!!}
then another C-c C-c, on b, yields
ABCF t f (MkC record { s = s ; t = .t } x) = ?
but this casing is immediately followed by an error:
B.t b != t of type A
when checking that the pattern MkC record { s = s ; t = .t } x has
type C t
Replacing .t with t' also does not solve this.
Any help indicating the reason behind this error and how to fix it would be greatly appreciated!
Edit
As answered below, the above problem may be due to a bug, but what of the converse case?
FCBA : ∀ {a} (f : A → A) → C (f a) → C a
FCBA {a} f (MkC record { s = s ; t = .(f a) } x) = ?
How would we solve this one? Which comes with the error
B.t b != f a of type A
when checking that the pattern MkC record { s = s ; t = .(f a) } x
has type C (f a)
Looks like a bug. If you swap the inaccessible pattern with the regular one, everything works:
ABCF : ∀ a → (f : A → A) → C a → C (f a)
ABCF .t f (MkC record { s = s ; t = t } x) = {!!}
But that a should anyway be implicit, since it's always inferrable from C a. Then there is no problem:
ABCF : ∀ {a} → (f : A → A) → C a → C (f a)
ABCF f (MkC record { s = s ; t = t } x) = {!!}
If you cannot pattern match directly due to the type being too specific, you can generalize it:
open import Relation.Binary.PropositionalEquality
FCBA : ∀ {a} (f : A → A) → C (f a) → C a
FCBA {a} f c with f a | inspect f a | c
... | .b | [ r ] | MkC record { s = s ; t = b } x = {!!}
Here we generalize f a to b and remember that f a ≡ b (in this case such remembering is not useful probably, but it's needed if you don't want to forget that b is actually f a). This allows to pattern match on c with swapping the inaccessible and the regular patterns like before.
But this is not a trick — it's an ugly hack. You should probably ask on the Agda mailing list why this swapping is required and whether this is the intended behavior.
I am learning how "typeclasses" are implemented in Agda. As an example, I am trying to implement Roman numerals whose composition with # would type-check.
I am not clear why Agda complains there is no instance for Join (Roman _ _) (Roman _ _) _ - clearly, it couldn't work out what natural numbers to substitute there.
Is there a nicer way to introduce Roman numbers that don't have "constructor" form? I have a constructor "madeup", which probably would need to be private, to be sure I have only "trusted" ways to construct other Roman numbers through Join.
module Romans where
data ℕ : Set where
zero : ℕ
succ : ℕ → ℕ
infixr 4 _+_ _*_ _#_
_+_ : ℕ → ℕ → ℕ
zero + x = x
succ y + x = succ (y + x)
_*_ : ℕ → ℕ → ℕ
zero * x = zero
succ y * x = x + (y * x)
one = succ zero
data Roman : ℕ → ℕ → Set where
i : Roman one one
{- v : Roman one five
x : Roman ten one
... -}
madeup : ∀ {a b} (x : Roman a b) → (c : ℕ) → Roman a c
record Join (A B C : Set) : Set where
field jo : A → B → C
two : ∀ {a} → Join (Roman a one) (Roman a one) (Roman a (one + one))
two = record { jo = λ l r → madeup l (one + one) }
_#_ : ∀ {a b c d C} → {{j : Join (Roman a b) (Roman c d) C}} → Roman a b → Roman c d → C
(_#_) {{j}} = Join.jo j
-- roman = (_#_) {{two}} i i -- works
roman : Roman one (one + one)
roman = {! i # i!} -- doesn't work
Clearly, if I specify the implicit explicitly, it works - so I am confident it is not the type of the function that is wrong.
Your example works fine in development version of Agda. If you are using a version older than 2.3.2, this passage from release notes could clarify why it doesn't compile for you:
* Instance arguments resolution will now consider candidates which
still expect hidden arguments. For example:
record Eq (A : Set) : Set where
field eq : A → A → Bool
open Eq {{...}}
eqFin : {n : ℕ} → Eq (Fin n)
eqFin = record { eq = primEqFin }
testFin : Bool
testFin = eq fin1 fin2
The type-checker will now resolve the instance argument of the eq
function to eqFin {_}. This is only done for hidden arguments, not
instance arguments, so that the instance search stays non-recursive.
(source)
That is, before 2.3.2, the instance search would completly ignore your two instance because it has a hidden argument.
While instance arguments behave a bit like type classes, note that they will only commit to an instance if there's only one type correct version in scope and they will not perform a recursive search:
Instance argument resolution is not recursive. As an example,
consider the following "parametrised instance":
eq-List : {A : Set} → Eq A → Eq (List A)
eq-List {A} eq = record { equal = eq-List-A }
where
eq-List-A : List A → List A → Bool
eq-List-A [] [] = true
eq-List-A (a ∷ as) (b ∷ bs) = equal a b ∧ eq-List-A as bs
eq-List-A _ _ = false
Assume that the only Eq instances in scope are eq-List and eq-ℕ.
Then the following code does not type-check:
test = equal (1 ∷ 2 ∷ []) (3 ∷ 4 ∷ [])
However, we can make the code work by constructing a suitable
instance manually:
test′ = equal (1 ∷ 2 ∷ []) (3 ∷ 4 ∷ [])
where eq-List-ℕ = eq-List eq-ℕ
By restricting the "instance search" to be non-recursive we avoid
introducing a new, compile-time-only evaluation model to Agda.
(source)
Now, as for the second part of the question: I'm not exactly sure what your final goal is, the structure of the code ultimately depends on what you want to do once you construct the number. That being said, I wrote down a small program that allows you to enter roman numerals without going through the explicit data type (forgive me if I didn't catch your intent clearly):
A roman numeral will be a function which takes a pair of natural numbers - the value of previous numeral and the running total. If it's smaller than previous numeral, we'll subtract its value from the running total, otherwise we add it up. We return the new running total and value of current numeral.
Of course, this is far from perfect, because there's nothing to prevent us from typing I I X and we end up evaluating this as 10. I leave this as an exercise for the interested reader. :)
Imports first (note that I'm using the standard library here, if you do not want to install it, you can just copy the definition from the online repo):
open import Data.Bool
open import Data.Nat
open import Data.Product
open import Relation.Binary
open import Relation.Nullary.Decidable
This is our numeral factory:
_<?_ : Decidable _<_
m <? n = suc m ≤? n
makeNumeral : ℕ → ℕ × ℕ → ℕ × ℕ
makeNumeral n (p , c) with ⌊ n <? p ⌋
... | true = n , c ∸ n
... | false = n , c + n
And we can make a few numerals:
infix 500 I_ V_ X_
I_ = makeNumeral 1
V_ = makeNumeral 5
X_ = makeNumeral 10
Next, we have to apply this chain of functions to something and then extract the running total. This is not the greatest solution, but it looks nice in code:
⟧ : ℕ × ℕ
⟧ = 0 , 0
infix 400 ⟦_
⟦_ : ℕ × ℕ → ℕ
⟦ (_ , c) = c
And finally:
test₁ : ℕ
test₁ = ⟦ X I X ⟧
test₂ : ℕ
test₂ = ⟦ X I V ⟧
Evaluating test₁ via C-c C-n gives us 19, test₂ then 14.
Of course, you can move these invariants into the data type, add new invariants and so on.
Prp : Set₁
Prp = Set
data _∧_ (P Q : Prp) : Prp where
∧-intro : P -> Q -> P ∧ Q
infixr 2 _∧_
data _∨_ (P Q : Prp) : Prp where
∨-intro₁ : P -> P ∨ Q
∨-intro₂ : Q -> P ∨ Q
infixr 1 _∨_
there is part of code from a sample code. I am just wondering what the meaning of the infixr, and why it be used there.
Thanks
This is significant not to write parentheses in expression like
a ∧ b ∨ c
a * b + c
infixr/infixl - is a power to (r=right, l=left), when it is used in infix(between) position