I've written some simple types for viewing Vect values:
data SnocVect : Vect n a -> Type where
SnocNil : SnocVect []
Snoc : (xs : Vect n a) -> (x : a) -> SnocVect (xs ++ [x])
data Split : (m : Nat) -> Vect n a -> Type where
MkSplit : (xs : Vect j a) -> (ys : Vect k a) ->
Split j (xs ++ ys)
Now it seems to me entirely reasonable that if I have a Split separating the last element of a vector, I should be able to convert that into a SnocVect:
splitToSnocVect : .{xs : Vect (S n) a} -> Split n xs ->
SnocVect xs
Unfortunately, I can't seem to find any way to implement this thing. In particular, I haven't found any way whatsoever to get it to let me pattern match on the Split n xs argument, without which I obviously can't get anywhere. I think the basic problem is that I have something of type
Split j (ps ++ [p])
and since ++ isn't injective, I need to work some sort of magic to convince the type checker that things make sense. But I don't understand this well enough to say for sure.
I finally got it! I imagine there must be a better way, but this works.
vectLengthConv : {auto a : Type} -> m = n ->
Vect m a = Vect n a
vectLengthConv prf = rewrite prf in Refl
splitToSnocVect' : .(n : Nat) -> .(xs : Vect m a) ->
.(m = n+1) -> Split n xs -> SnocVect xs
splitToSnocVect' n (ys ++ zs) prf (MkSplit {k} ys zs)
with (vectLengthConv (plusLeftCancel n k 1 prf))
splitToSnocVect' n (ys ++ []) prf
(MkSplit {k = Z} ys []) | Refl impossible
splitToSnocVect' n (ys ++ (z :: [])) prf
(MkSplit {k = (S Z)} ys (z :: [])) | lenconv =
Snoc ys z
splitToSnocVect' n (ys ++ zs) prf
(MkSplit {k = (S (S k))} ys zs) | Refl impossible
splitToSnocVect : .{n : Nat} -> .{xs : Vect (S n) a} ->
Split n xs -> SnocVect xs
splitToSnocVect {n} {xs} splt =
splitToSnocVect' n xs (plusCommutative 1 n) splt
Edit
David Christiansen suggests nixing vectLengthConv and instead using cong {f=\len=>Vect len a} (plusLeftCancel n k 1 prf) in the with clause. This helps a little.
Related
I'm doing some development in Idris and I've being getting into the following problem. Say we have 3 vectors:
xs : Vect len a
ys : Vect len a
zs : Vect len' a
and say we also have
samelen : len = len'
Finally, we also have the following equalities:
xsys : xs = ys
yszs : ys = zs
In the first equality, we have an equality for the type Vect len a while in the second for Vect len' a. Now we want to establish:
xsza : xs = zs
I've been having a hard time making this work. In particular, trans needs equality between the same types, but that is not the case here. How can transitivity be used here to achieve xsza?
Why, sure:
xszs : {A : Type} -> {len, len' : Nat} ->
(xs, ys : Vect len A) -> (zs : Vect len' A) ->
len = len' ->
xs = ys -> ys = zs ->
xs = zs
xszs {A} {len} {len'=len} xs ys zs Refl = trans
I think it's important to know that this basically has to be a function. You cannot use the sameLen proof to replace len with len' in the types of things that are already in scope. That is, if your type signatures were all top level, Idris could never be convinced that zs : Vect len a. You have to use an auxiliary function. In the above function, len' is matched to len, justified by matching the Refl, before the zs variable is introduced. You might argue that's clearly false, as zs comes before the Refl argument, but, since Idris is a total language, the compiler is allowed to make life easier for you by implicitly reordering the abstraction and the matching and all that jazz. In effect, right before the Refl is matched, before zs is introduced, the goal type is (zs : Vect len' A) -> xs = ys -> ys = zs -> xs = zs, but the match rewrites that to (zs : Vect len A) -> ?etc, and zs is introduced with a nicer type.
Do note that the len = len' thing is really just not necessary, though. This works:
xszs : {A : Type} -> {len, len' : Nat} ->
(xs, ys : Vect len A) -> (zs : Vect len' A) ->
xs = ys -> ys = zs -> xs = zs
xszs {A} {len} {len'=len} xs xs xs Refl Refl = Refl
Or even
xszs : {A : Type} -> {len, len' : Nat} ->
(xs, ys : Vect len A) -> (zs : Vect len' A) ->
xs = ys -> ys = zs -> xs = zs
xszs xs ys zs = trans
Given:
*section3> :module Data.Vect
*section3> :let e = the (Vect 0 Int) []
*section3> :let xs = the (Vect _ _) [1,2]
*section3> decEq xs e
(input):1:7:When checking argument x2 to function Decidable.Equality.decEq:
Type mismatch between
Vect 0 Int (Type of e)
and
Vect 2 Integer (Expected type)
Specifically:
Type mismatch between
0
and
2
Why must the Nat arguments equal each other for DecEq?
Note - posted in https://groups.google.com/forum/#!topic/idris-lang/qgtImCLka3I originally
decEq is for homogenous propositional equality:
||| Decision procedures for propositional equality
interface DecEq t where
||| Decide whether two elements of `t` are propositionally equal
total decEq : (x1 : t) -> (x2 : t) -> Dec (x1 = x2)
As you can see, x1 and x2 are both of type t. In your case, you have x1 : Vect 2 Integer and x2 : Vect 0 Int. These are two different types.
You can write your own heterogenous equality decider for Vectors of the same element type by first checking their lengths, then delegating to the homogenous version:
import Data.Vect
vectLength : {xs : Vect n a} -> {ys : Vect m a} -> xs = ys -> n = m
vectLength {n = n} {m = n} Refl = Refl
decEqVect : (DecEq a) => (xs : Vect n a) -> (ys : Vect m a) -> Dec (xs = ys)
decEqVect {n = n} {m = m} xs ys with (decEq n m)
decEqVect xs ys | Yes Refl = decEq xs ys
decEqVect xs ys | No notEq = No (notEq . vectLength)
I'm playing around with Idris and I came across something which confuses me a little:
The following type checks:
conc : Vect n a -> Vect m a -> Vect (n+m) a
conc [] ys = ys
conc (x :: xs) ys = x :: (conc xs ys)
but this doesn't:
conc : Vect n a -> Vect m a -> Vect (m+n) a
conc [] ys = ys
conc (x :: xs) ys = x :: (conc xs ys)
with the following error:
When checking right hand side of conc with expected type
Vect (m + 0) a
Type mismatch between
Vect m a (Type of ys)
and
Vect (plus m 0) a (Expected type)
Specifically:
Type mismatch between
m
and
plus m 0
Equivalently xs++ys type checks but ys++xs doesn't even though they would both match the type definition of having length n+m.
This surprises me a little as addition is commutative. Is there anything I can do (perhaps with constraints?) to the function signature to get both xs++ys and ys++xs expressions type checking?
This is a common topic of confusion for beginners in Idris.
The problem in this case in second conc version:
conc : Vect n a -> Vect m a -> Vect (m+n) a
conc [] ys = ys
Idris cannot apply addition commutativity because Nat plus commutativity is a theorem from the compiler point of view. Here its type:
Idris> :t plusCommutative
plusCommutative : (left : Nat) -> (right : Nat) -> left + right = right + left
There're no general rules to tell you which theorem to choose and to apply. Of course, some heuristics can be made for some simple cases, like Nat commutativity. But this also can make difficult to understand some other cases.
The other thing you need to consider is definition of plus:
Idris> :printdef plus
plus : Nat -> Nat -> Nat
plus 0 right = right
plus (S left) right = S (plus left right)
Function plus defined in a such way that is does pattern matching on its first argument. Idris actually can perform this pattern matching in types. So in first version, where
conc : Vect n a -> Vect m a -> Vect (n+m) a
conc [] ys = ys
you have (0 + m) in type and Idris can replace plus 0 m with m and everything typechecks. plus m 0 would work if you define your + operator by pattern matching on second argument. For example, this compiles:
infixl 4 +.
(+.) : Nat -> Nat -> Nat
n +. Z = n
n +. (S m) = S (n +. m)
conc : Vect n a -> Vect m a -> Vect (m +. n) a
conc [] ys = ys
conc (x :: xs) ys = x :: (conc xs ys)
But it's obvious that writing new operator for every case you need is horrible. So to make your second version compilable you should use rewrite ... in syntax in Idris. You need next theorems:
Idris> :t plusZeroRightNeutral
plusZeroRightNeutral : (left : Nat) -> left + 0 = left
Idris> :t plusSuccRightSucc
plusSuccRightSucc : (left : Nat) -> (right : Nat) -> S (left + right) = left + S right
Idris> :t sym
sym : (left = right) -> right = left
And here is version which compiles:
conc : Vect n a -> Vect m a -> Vect (m + n) a
conc {m} [] ys = rewrite plusZeroRightNeutral m in ys
conc {n=S k} {m} (x :: xs) ys = rewrite (sym $ plusSuccRightSucc m k) in x :: (conc xs ys)
I'm not explaining here how rewriting and theorem proving works here. This is a topic of another question if you don't understand something. But you can read about that in tutorial (or wait for The Book release :) .
Given the following Idris code:
import Data.Vect
import Data.Fin
%default total
fins : Vect n (Fin n)
fins {n = Z} = []
fins {n = S n} = FZ :: map FS fins
Permutation : Nat -> Type
Permutation n = {a : Type} -> Vect n a -> Vect n a
permutations : {n : Nat} -> Vect (fact n) (Permutation n)
permutations {n = Z} = [id]
permutations {n = S n} =
rewrite multCommutative (S n) (fact n) in
concat $ map inserts (permutations {n = n})
where
inserts : Permutation k -> Vect (S k) (Permutation (S k))
inserts pi = map (\i => \(x :: xs) => insertAt i x . pi $ xs) fins
I am getting the following error message from Idris 0.9.16 (and no further details):
Type checking .\Permutations.idr
Permutations.idr:15:14:Universe inconsistency
However, by changing it just so slightly, so that the second clause of permutations becomes
permutations {n = S n} =
rewrite multCommutative (S n) (fact n) in
concat . map inserts $ permutations {n = n}
then it suddenly typechecks.
Is there some special magic going on inside Idris perhaps in the handling of ($) and (.), similar to what GHC does so that they work in the presence of higher-rank types?
As of Idris 0.10.2, my original code (using concat $ map inserts (permutations {n = n}) in the definition of permutations) typechecks without hiccup.
I'm trying to write in Idris a function that create a Vect by passing the size of the Vect and a function taking the index in parameter.
So far, I've this :
import Data.Fin
import Data.Vect
generate: (n:Nat) -> (Nat -> a) ->Vect n a
generate n f = generate' 0 n f where
generate': (idx:Nat) -> (n:Nat) -> (Nat -> a) -> Vect n a
generate' idx Z f = []
generate' idx (S k) f = (f idx) :: generate' (idx + 1) k f
But I would like to ensure that the function passed in parameter is only taking index lesser than the size of the Vect.
I tried that :
generate: (n:Nat) -> (Fin n -> a) ->Vect n a
generate n f = generate' 0 n f where
generate': (idx:Fin n) -> (n:Nat) -> (Fin n -> a) -> Vect n a
generate' idx Z f = []
generate' idx (S k) f = (f idx) :: generate' (idx + 1) k f
But it doesn't compile with the error
Can't convert
Fin n
with
Fin (S k)
My question is : is what I want to do possible and how ?
The key idea is that the first element of the vector is f 0, and for the tail, if you have k : Fin n, then FS k : Fin (S n) is a "shift" of the finite number that increments its value and its type at the same time.
Using this observation, we can rewrite generate as
generate : {n : Nat} -> (f : Fin n -> a) -> Vect n a
generate {n = Z} f = []
generate {n = S _} f = f 0 :: generate (f . FS)
Another possibility is to do what #dfeuer suggested and generate a vector of Fins, then map f over it:
fins : (n : Nat) -> Vect n (Fin n)
fins Z = []
fins (S n) = FZ :: map FS (fins n)
generate' : {n : Nat} -> (f : Fin n -> a) -> Vect n a
generate' f = map f $ fins _
Proving generate f = generate' f is left as en exercise to the reader.
Cactus's answer appears to be about the best way to get what you asked for, but if you want something that can be used at runtime, it will be quite inefficient. The essential reason for this is that to weaken a Fin n to a Fin n+m requires that you completely deconstruct it to change the type of its FZ, and then build it back up again. So there can be no sharing at all between the Fin values produced for each vector element. An alternative is to combine a Nat with a proof that it is below a given bound, which leads to the possibility of erasure:
data NFin : Nat -> Type where
MkNFin : (m : Nat) -> .(LT m n) -> NFin n
lteSuccLeft : LTE (S n) m -> LTE n m
lteSuccLeft {n = Z} prf = LTEZero
lteSuccLeft {n = (S k)} {m = Z} prf = absurd (succNotLTEzero prf)
lteSuccLeft {n = (S k)} {m = (S j)} (LTESucc prf) = LTESucc (lteSuccLeft prf)
countDown' : (m : Nat) -> .(m `LTE` n) -> Vect m (NFin n)
countDown' Z mLTEn = []
countDown' (S k) mLTEn = MkNFin k mLTEn :: countDown' k (lteSuccLeft mLTEn)
countDown : (n : Nat) -> Vect n (NFin n)
countDown n = countDown' n lteRefl
countUp : (n : Nat) -> Vect n (NFin n)
countUp n = reverse $ countDown n
generate : (n : Nat) -> (NFin n -> a) -> Vect n a
generate n f = map f (countUp n)
As in the Fin approach, the function you pass to generate does not need to work on all naturals; it only needs to handle ones less than n.
I used the NFin type to explicitly indicate that I want the LT m n proof to be erased in all cases. If I didn't want/need that, I could just use (m ** LT m n) instead.