<div dir="ltr"><div><div><div><div><div><div><div>(If I'm not mistaken) way back in Eliminating Dependent Pattern Matching (at least), it is remarked that the translation relies on both K (or, an appropriate heterogeneous equality) and disjointness and injectivity of constructors. So it would not be a surprise that removing K does not remove disjointness of constructors.<br>
<br></div>It's pretty easy to see that this is not going to work if the 'data' construct that allows for pattern matching does some form of quotienting, though. And higher inductive types allow you to assert that something is a (normal) quotient, among other things.<br>
<br></div>Getting rid of this is a big deal, though. If you just throw it away, then I don't think definitions like the following work:<br><br></div> zip : {A B : Set} {n : ℕ} -> Vec A n -> Vec B n -> Vec (A × B) n<br>
</div> zip [] [] = []<br></div> zip (x :: xs) (y :: ys) = (x , y) :: zip xs ys<br><br></div>The ability to elide the two other cases relies on the fact that they cause unification errors, zero ≠ suc n. But, this presumes disjointness of the natural numbers. If we aren't allowed that, then we must write these cases, and explicitly appeal to disjointness proofs. Except, Agda (for instance) isn't equipped for such a thing; we have no way of accessing a propositional 'zero = suc n' in those cases to hand off to a lemma.<br>
<br></div><div>Also, you presumably lose the ability to write things like:<br><br></div><div> foo : ∀ n -> Fin n -> ...<br></div><div> foo zero () ...<br> ...</div><div><br></div><div>and similarly have no real recourse for that case in Agda.<br>
<br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jul 10, 2013 at 10:52 AM, Dan Licata <span dir="ltr"><<a href="mailto:drl@cs.cmu.edu" target="_blank">drl@cs.cmu.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Is this a bug or a design decision? It seems like this example is in<br>
accord with the description of without-K in the release notes, but<br>
that allowing matching when the indices are constructors has some<br>
interesting consequences. In particular, it means that, in a core<br>
theory without universes, without-K pattern matching cannot be<br>
compiled to J, because you can prove disjointness (and injectivity) of<br>
constructors, and that bool is an hset (code below), just using<br>
pattern matching on the identity type. As far as I know, disjointness<br>
and the hset-ness of bool require a universe/large elims to prove. Of<br>
course, Agda has universes, and it is possible that without-K pattern<br>
matching could be compiled to J + uses of large elims to code up these<br>
constructions on constructors. But I would personally prefer it if<br>
without-K pattern matching did not build these things in, because it<br>
means we need to use two hacks (rather than just one :) ) to implement<br>
higher inductives.<br>
<br>
-Dan<br>
<br>
-- checks in Agda 2.3.2.1<br>
{-# OPTIONS --without-K #-}<br>
<br>
module WithoutK where<br>
<br>
data Nat : Set where<br>
Z : Nat<br>
S : Nat -> Nat<br>
<br>
data Bool : Set where<br>
True : Bool<br>
False : Bool<br>
<br>
data Void : Set where<br>
<br>
data _==_ {A : Set} (x : A) : A -> Set where<br>
Refl : x == x<br>
<br>
injective : {m n : Nat} -> S m == S n -> m == n<br>
injective Refl = Refl<br>
<br>
disjoint : {m : Nat} -> S m == Z -> Void<br>
disjoint ()<br>
<br>
bool-hset : (b : Bool) -> (p : b == b) -> p == Refl<br>
bool-hset True Refl = Refl<br>
bool-hset False Refl = Refl<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
On Wed, Jul 10, 2013 at 5:56 AM, Altenkirch Thorsten<br>
<<a href="mailto:psztxa@exmail.nottingham.ac.uk">psztxa@exmail.nottingham.ac.uk</a>> wrote:<br>
> This looks like a bug – please add it to the bug tracker.<br>
><br>
> We really need to understand what we are doing when checking wether pattern<br>
> satisfy the —without-K condition. It seems that Conor's work on translating<br>
> pattern matching to eliminators (with J and K) would be a good starting<br>
> point.<br>
><br>
> At the same time we know that many types support UIP by structure. Michael<br>
> Hedberg showed that all types with a decidable equality support UIP and it<br>
> is not hard to see that this can be extended to stable equality (non-not<br>
> closed). (Little puzzle: without extensionality – are there any types which<br>
> have stable but not decidable equality ?)<br>
><br>
> We also want to quantify over all HSets (I.e. types with UIP) and so on.<br>
><br>
> Thorsten<br>
><br>
> From: Jason Reed <<a href="mailto:jcreed@gmail.com">jcreed@gmail.com</a>><br>
> Date: Tue, 9 Jul 2013 16:31:22 +0100<br>
> To: "<a href="mailto:agda@lists.chalmers.se">agda@lists.chalmers.se</a>" <<a href="mailto:agda@lists.chalmers.se">agda@lists.chalmers.se</a>><br>
> Subject: [Agda] another possible without-K problem<br>
><br>
> I'm experiencing something that I think is a violation of the intent of the<br>
> --without-K flag, similar to what Thorsten was talking about in<br>
> <a href="https://lists.chalmers.se/pipermail/agda/2012/004104.html" target="_blank">https://lists.chalmers.se/pipermail/agda/2012/004104.html</a>.<br>
><br>
> The following file checks fine for me under current darcs Agda:<br>
><br>
> <<<begin>>><br>
> {-# OPTIONS --without-K #-}<br>
><br>
> module Test where<br>
><br>
> data S1 : Set where<br>
> base : S1<br>
><br>
> module test where<br>
> data _≡_ {A : Set} (a : A) : A → Set where<br>
> refl : a ≡ a<br>
><br>
> bad : (p q : base ≡ base) -> p ≡ q<br>
> bad refl refl = refl<br>
><br>
> module test2 where<br>
> data _≡_ {A : Set} : A → A → Set where<br>
> refl : {x : A} → x ≡ x<br>
><br>
> bad : (p q : base ≡ base) -> p ≡ q<br>
> bad refl refl = refl<br>
> <<<end>>><br>
><br>
> Note that this covers both the possible definitions of the identity type<br>
> mentioned by Guillaume in<br>
> <a href="https://lists.chalmers.se/pipermail/agda/2012/004105.html" target="_blank">https://lists.chalmers.se/pipermail/agda/2012/004105.html</a><br>
><br>
> Any ideas what should be done here? Does the K-check need to be further<br>
> strengthened when there aren't parameters around? Am I misunderstanding<br>
> something trivial?<br>
><br>
><br>
> This message and any attachment are intended solely for the addressee and<br>
> may contain confidential information. If you have received this message in<br>
> error, please send it back to me, and immediately delete it. Please do not<br>
> use, copy or disclose the information contained in this message or in any<br>
> attachment. Any views or opinions expressed by the author of this email do<br>
> not necessarily reflect the views of the University of Nottingham.<br>
><br>
> This message has been checked for viruses but the contents of an attachment<br>
> may still contain software viruses which could damage your computer system,<br>
> you are advised to perform your own checks. Email communications with the<br>
> University of Nottingham may be monitored as permitted by UK legislation.<br>
><br>
><br>
><br>
</div></div><div class="HOEnZb"><div class="h5">> _______________________________________________<br>
> Agda mailing list<br>
> <a href="mailto:Agda@lists.chalmers.se">Agda@lists.chalmers.se</a><br>
> <a href="https://lists.chalmers.se/mailman/listinfo/agda" target="_blank">https://lists.chalmers.se/mailman/listinfo/agda</a><br>
><br>
_______________________________________________<br>
Agda mailing list<br>
<a href="mailto:Agda@lists.chalmers.se">Agda@lists.chalmers.se</a><br>
<a href="https://lists.chalmers.se/mailman/listinfo/agda" target="_blank">https://lists.chalmers.se/mailman/listinfo/agda</a><br>
</div></div></blockquote></div><br></div>