Helper Function to Determine if Nat `mod` 5 == 0 - idris

Xash provided me with a helpful answer on Function to Determine if Nat is Divisible by 5 at Compile-Time (that I re-named from my original long name):
onlyModBy5 : (n : Nat) -> n `modNat` 5 = 0 -> Nat
onlyModBy5 n prf = n
A previous answer educated me how to run it on the REPL using the Refl argument:
-- 5 % 5 == 0, so it should compile
*Test> onlyModBy5 5 Refl
5 : Nat
-- 7 % 5 == 2, so it should not compile
*Test> onlyModBy5 7 Refl
(input):1:12:When checking an application of function Main.onlyModBy5:
Type mismatch between
x = x (Type of Refl)
and
modNat 7 5 = 0 (Expected type)
Specifically:
Type mismatch between
2
and
0
Then, I tried to define a helper function that would provide the second prf (proof) argument for conciseness. In other words, I'd prefer the caller of this function to not have to provide the Refl argument.
onlyModBy5Short : (n : Nat) -> Nat
onlyModBy5Short n = onlyModBy5 n Refl
But, it does not compile:
When checking right hand side of onlyModBy5Short with expected type
Nat
When checking an application of function Main.onlyModBy5:
Type mismatch between
0 = 0 (Type of Refl)
and
modNat n 5 = 0 (Expected type)
Specifically:
Type mismatch between
0
and
Prelude.Nat.modNatNZ, mod' n 4 SIsNotZ n n 4
Holes: Main.onlyModBy5Short
How, if possible, can this function be written?

You can make onlyModBy5's second argument an auto argument:
onlyModBy5 : (n : Nat) -> {auto prf : n `modNat` 5 = 0} -> Nat
onlyModBy5 n = n
This works because for a given literal value of n, n `modNat` 5 can always be reduced, and so n `modNat` 5 = 0 will always reduce to 0 = 0 (in which case the constructor Refl has the right type) unless n is truly not divisible by 5.
Indeed, this will allow you to typecheck
foo : Nat
foo = onlyModBy5 25
but reject
bar : Nat
bar = onlyModBy5 4

Related

Why does Idris give me Type mismatch error for the following code?

I am a newbie trying to learn Idris and wanted to create a function test that returns a Vector whose type is parameterized by the function argument.
vecreplicate : (len : Nat) -> (x : elem) -> Vect len elem
vecreplicate Z x = []
vecreplicate (S k) x = x :: vecreplicate k x
test : (k:Nat) -> Nat -> Vect k Int
test Z = vecreplicate Z (toIntegerNat Z)
test k = vecreplicate k (toIntegerNat k)
When I try to compile the code with Idris I get the following type error
Type mismatch between
Vect len elem (Type of vecreplicate len x)
and
Nat -> Vect 0 Int (Expected type)
Specifically:
Type mismatch between
Vect len
and
\uv => Nat -> uv
Why am I getting this error?
test : (k:Nat) -> Nat -> Vect k Int takes two arguments, but you only match on k. That's why the expected type is a lambda (Nat -> Vect 0 Int). Just drop one Nat: test : (k : Nat) -> Vect k Int.
Also, toIntegerNat returns Integer not Int. :search Nat -> Int returns toIntNat, so that's what you want to use there.

Why doesn't equality involving "mod" not typecheck in Idris?

Why won't the following typecheck:
v1 : mod 3 2 = 1
v1 = Refl
Yet this will typecheck fine:
v2 : 3 - 2 = 1
v2 = Refl
It happens due to partiality of mod function (thanks to #AntonTrunov clarification). It's polymorphic and by default numeral constants are Integers.
Idris> :t mod
mod : Integral ty => ty -> ty -> ty
Idris> :t 3
3 : Integer
Idris> :t mod 3 2
mod 3 2 : Integer
For Integer type mod function is not total.
Instead use modNatNZ function so everything type checks perfectly and works.
v1 : modNatNZ 3 2 SIsNotZ = 1
v1 = Refl

Auto implicit arg stops working when type is given a name

While writing this answer, I noticed that while this works as expected:
onlyModBy5 : (n : Nat) -> {auto prf : n `modNat` 5 = 0} -> Nat
onlyModBy5 n = n
foo : Nat
foo = onlyModBy5 25
but as soon as I give a name to the property it stops working:
Divides : Nat -> Nat -> Type
Divides n k = k `modNat` n = 0
onlyModBy5 : (n : Nat) -> {auto prf : 5 `Divides` n} -> Nat
onlyModBy5 n = n
foo : Nat
foo = onlyModBy5 25
now filling the auto arg fails with
Can't find a value of type
Divides 5 25
Why is Idris unable to see through Divides's definition?
I am not sure if this is the reason, but modNat is not total. That would be a good reason to trip idris.
divides : Nat -> Nat -> Nat
divides n k = n `modNat` k
onlyModBy5 : (n : Nat) -> {auto prf : n `divides` 5 = 0 } -> Nat
onlyModBy5 n = n
foo : Nat
foo = onlyModBy5 25
For some reason this already fails as well (just indirecting once from the original version).

How does "There" work in the idris tutorial, page 11, section 3.4.4?

Here is the example from the tutorial, slightly modified for simplicity:
data Vect : Nat -> (b:Type) -> Type where
Nil : Vect Z a
(::) : a -> Vect k a -> Vect (S k) a
data Elem : a -> Vect n a -> Type where
Here : {x:a} -> {xs:Vect n a} -> Elem x (x :: xs)
There : {x,y:a} -> {xs:Vect n a} -> Elem x xs -> Elem x (y :: xs)
testVec : Vect 4 Int
testVec = 3 :: 4 :: 5 :: 6 :: Nil
inVect : Elem 4 testVec
inVect = There Here
I can't understand how There verifies that the value is correct.
As far as I understand it, There works like a function, so it takes the
element of type Here, which when filling in the holes, corresponds to Elem 3 testVec, then sets the first value of testVec to y, and the rest to xs. But since, y isn't used anywhere, I would except this not to cause any restriction.
However, when I try
inVectBroken : Elem 2 testVec
inVectBroken = There Here
I get an error:
When checking an application of constructor There:
Type mismatch between
Elem x (x :: xs) (Type of Here)
and
Elem 2 [4, 5, 6] (Expected type)
Specifically:
Type mismatch between
2
and
4
Can someone explain to me how the above code works (magically?) to restrict There to the tail of Vect?
Here 4 (x :: xs) is a proof that 4 is at the head of (x :: xs), so x = 4. There takes a proof Elem 4 xs that 4 is somewhere in xs and so proofs Elem 4 (y :: xs), that 4 is still somewhere down a extended list. That is where the y goes to. It does not matter what y actually is, it just allows to extend the proof to larger lists. For example:
in1 : Elem 4 (4 :: Nil)
in1 = Here
in2 : Elem 4 (3 :: 4 :: Nil)
in2 = There in1
in3 : Elem 4 (8 :: 4 :: Nil)
in3 = There in1
By the types you see that not the element 4 changes throughout the proof but the list.

(xs : Vect n elem) -> Vect (n * 2) elem

The book Type Driven Development with Idris presents this exercise:
Define a possible method that fits the signature:
two : (xs : Vect n elem) -> Vect (n * 2) elem
I tried:
two : (xs : Vect n elem) -> Vect (n * 2) elem
two xs = xs ++ xs
But I got the following error:
*One> :r
Type checking ./One.idr
One.idr:9:5:When checking right hand side of two:
Type mismatch between
Vect (n + n) elem (Type of xs ++ xs)
and
Vect (mult n 2) elem (Expected type)
Specifically:
Type mismatch between
plus n n
and
mult n 2
Holes: Hw1.two
If I have a Vector of size N, and need a Vector of size N*2, then appending it to itself seems reasonable.
What am I doing wrong?
Short answer
Change the type signature to two : (xs : Vect n elem) -> Vect (n + n) elem.
If you really need it that way
Getting to Vect (n * 2) elem is a bit complicated. Here:
two' : Vect n elem -> Vect (n * 2) elem
two' {n} xs = rewrite multCommutative n 2 in rewrite plusZeroRightNeutral n in xs ++ xs
The reason you got that error message is that equality in typechecking is equality after reduction to normal form. n + n and mult n 2 are equal, but their normal forms aren't. (mult n 2 is what n * 2 reduces to after resolving the typeclass.)
You can see the definition of mult like so:
*kevinmeredith> :printdef mult
mult : Nat -> Nat -> Nat
mult 0 right = 0
mult (S left) right = plus right (mult left right)
It works by pattern matching on the first argument. Since the first argument in the type signature of two is n, mult can't be reduced at all. multCommutative will help us flip it around:
*kevinmeredith> :t multCommutative
multCommutative : (left : Nat) ->
(right : Nat) -> left * right = right * left
Our best tool to apply that equality is rewrite, like in my definition of two'. (run :t replace at the REPL if you want to see how to do it the hard way) In the rewrite foo in bar construction, foo is something of type a = b and bar has the type of the outer expression, but with all as replaced by bs. In my two' above, I first used it to change Vect (n * 2) to Vect (2 * n). This lets mult reduce. If we look at mult above, and apply it to 2 i.e. S (S Z) and n, you get plus n (mult (S Z) n, and then plus n (plus n (mult Z n)), and then plus n (plus n Z). You don't have to work out the reduction yourself, you can just apply the rewrite and put a hole on the end:
two' : Vect n elem -> Vect (n * 2) elem
two' {n} xs = rewrite multCommutative n 2 in ?aaa
Then ask Idris:
*kevinmeredith> :t aaa
elem : Type
n : Nat
xs : Vect n elem
_rewrite_rule : plus n (plus n 0) = mult n 2
--------------------------------------
aaa : Vect (plus n (plus n 0)) elem
plus n Z doesn't reduce because plus is defined by recursion on its first argument, just like mult. plusZeroRightNeutral gets you the equality you need:
*kevinmeredith> :t plusZeroRightNeutral
plusZeroRightNeutral : (left : Nat) -> left + 0 = left
I used the same technique with rewrite again.
:search will let you search the library for inhabitants of a given type. You'll often find someone has done the work of proving things for you.
*kevinmeredith> :s (n : Nat) -> n + 0 = n
= Prelude.Nat.multOneLeftNeutral : (right : Nat) ->
fromInteger 1 * right = right
= Prelude.Nat.plusZeroRightNeutral : (left : Nat) ->
left + fromInteger 0 = left
*kevinmeredith> :s (n, m : Nat) -> n * m = m * n
= Prelude.Nat.multCommutative : (left : Nat) ->
(right : Nat) -> left * right = right * left
(This answer is for Idris version 0.9.20.1)